Project Management Nation: Tools, Techniques, and Goals for the New and Practicing It Project Manager [1st ed.] 0471139262, 9780471139263

Citation preview

Pr oj ect Managem ent Nat ion: Tools, Techniques, and Goals for t he New and Pr act icing I T Pr oj ect Manager

by Jason Charvat I SBN: 0471139262

Guides every proj ect m anager in responding t o challenges prom pt ly, wit h cert aint y and expert ise.

Ta ble of Con t e n t s Proj ect Managem ent Nat ion—Tools, Techniques, and Goals for t he New and Pract icing I T Proj ect m anager Foreword Preface Chapt er 1 - Underst anding Proj ect St rat egy Chapt er 2 - Becom ing an I T Proj ect Manager Chapt er 3 - Proj ect Concept s Chapt er 4 - The Proj ect Analysis Chapt er 5 - Planning for Success Chapt er 6 - Execut ing t he Proj ect Chapt er 7 - Cont rolling t he Proj ect Chapt er 8 - I m plem ent ing t he Proj ect Chapt er 9 - Closing t he Proj ect Glossary I ndex List of Figures List of Tables

Proj ect Managem ent N at ion—Tools, Techniques, and Goals for t he N ew and Pract icing I T Proj ect m anager Jason Charvat

John Wiley & Sons, I nc. Copyright ?2002 by John Wiley & Sons, I nc., New York. All right s reserved. No part of t his publicat ion m ay be reproduced, st ored in a ret rieval syst em or t ransm it t ed in any form or by any m eans, elect ronic, m echanical, photocopying, recording, scanning or ot herwise, except as perm it t ed under Sect ions 107 or 108 of t he 1976 Unit ed St at es Copyright Act , wit hout eit her t he prior writ t en perm ission of t he Publisher, or aut horizat ion t hrough paym ent of t he appropriat e per- copy fee t o t he Copyright Clearance Cent er, 222 Rosewood Drive, Danvers, MA 01923, ( 508) 750- 8400, fax ( 508) 750 4470. Request s t o t he Publisher for perm ission should be addressed t o t he Perm issions Depart m ent , John Wiley & Sons, I nc., 605 Third Avenue, New Yor k , NY 10158 -0012, ( 212) 850 -6011, fax ( 212) 850 -6008, E- Mail: < PERMREQ@WI LEY.COM> . This publicat ion is designed t o provide accurat e and aut horit at ive inform at ion in regard t o t he subj ect m at t er covered. I t is sold wit h t he underst anding t hat t he publisher is not engaged in rendering professional services. I f professional advice or ot her expert assist ance is required, t he services of a com pet ent professional person should be sought . I SBN 0 - 471 -13926- 2 10 9 8 7 6 5 4 3 2 1 Acknow ledgm ent s I would like t o recognize t he support of t he m anagem ent t eam at RCG I nform at ion Technology, I nc., who provided m e wit h an environm ent in which t o apply m yself. I would like t o t hank Gary Hau for helping m e solve t he m any det ailed I T developm ent issues one needs t o consider when m anaging com plex I T proj ect s. My grat it ude is ext ended t o Dr. J. Davidson Fram e from t he Universit y of Managem ent and Technology in Washingt on, D.C., for his discussions and opinions on t he field of proj ect m anagem ent . Thanks go t o Mat t hew Holt , senior edit or at John Wiley & Sons. To Bob Fairchild and Rick Freedm an, t hanks for your insight and reviews. To all t hose people t hat have cont ribut ed t o t he publicat ion of t his book, I t hank you collect ively. Last ly, special t hanks go t o m y wife Liesl and son Mat t hew, who have kept m y life so organized during all t hese years.

ABOUT TH E AUTH OR Jason ( Jay) Charvat is an accom plished consult ant Proj ect Managem ent Professional in t he fields of Syst em s Engineering and I nform at ion Technology, where he com plet ed m any successful proj ect s in t he Defense, Logist ics, Manufact uring, Publishing, Governm ent al, Pharm aceut ical, Cellular and Telecom m unicat ions indust ry vert icals. He has ext ensive knowledge on proj ect m et hodologies, proj ect processes, and pract ical t echniques used in t he com plet ion of proj ect s. He is a cert ified consult ant and has consult ed regularly t hroughout t he US. He is a m em ber of t he Proj ect Managem ent I nst it ut e ( PMI ) . He holds a BS ( I nform at ion Sciences) degree in add it ion t o num erous professionals qualificat ions from t he Unit ed Kingdom . He has served as a com m issioned Airforce capt ain, specializing in t he inform at ion t echnology environm ent . Jay serves as a proj ect m anagem ent consult ant and senior m anager for RCG I nform at ion Technology, I nc., in New Jersey. He can be reached at < j aycharvat @hot m ail.com > or www.j asoncharvat .com .

For e w or d More people work on I T ( inform at ion t echnology) proj ect s t han on any ot her cat egory of proj ect . I n fact , if you were t o conduct a st at ist ical invest igat ion of who is doing what on proj ect s im plem ent ed t hroughout t he world, you would likely find t hat m ore people are working on I T proj ect s t han on all ot her t ypes com bined! Unt il recent ly, t hose of us who have st udied proj ect m anagem ent over t he years have em phasized t he universalit y of proj ect issues encount ered by proj ect workers, regardless of t he specific nat ure of t he proj ect s being undertaken. Aft er all, a schedule is a schedule, whet her it has been creat ed for a const ruct ion proj ect , an FDA approval effort , or a soft ware developm ent undert aking. Thus, it is possible t o learn key scheduling t ools wit hout worrying about t he specific cont ext in which t he schedule occurs. Sim ilar argum ent s can be m ade about budget and resource allocat ion t ools. Wit hout quest ion, it is rem arkable how t he experiences of people working on different t ypes of proj ect s are so sim ilar. When const ruct ion proj ect m anagers get t oget her wit h soft ware proj ect m anagers, t hey find t hat t hey have m any com m on experiences t o share. For exam ple, t o t he ext ent t hat bot h groups use borrowed resources ( called m at rix m anagem ent ) , t hey face t he com m on sit uat ion where proj ect m anagers do not cont rol t he resources wit h which t hey m ust work. And t hey bot h operat e in environm ent s where t here is a t endency for proj ect scope t o grow as t he proj ect is carried out ( called scope creep) . Wit h t he onset of t he new m illennium , we have begun t o t urn our at t ent ion t o t he special circum st ances governing proj ect work in different business areas. I n part icular, we now recognize t hat knowledge- based proj ect s face a different set of challenges t han t he challenges t hat t radit ional proj ect s in t he const ruct ion and defense indust ries encount er. For exam ple, knowledge- based proj ect s are heavily orient ed t oward dealing wit h int angibles. Knowledge it self is ephem eral and ever- changing. Because knowledge is abst ract , it is hard t o capt ure and art iculat e cust om er needs and t o convert t hese int o concret e requirem ent s. These are t he t ypes of issues t hat workers on knowledge- based proj ect s m ust cont end wit h day by day. I n Proj ect Managem ent Nat ion, Jason P. Charvat deals explicit ly wit h t he challenges faced by project professionals working on I T proj ect s. He begins by recognizing t hat t he key players on I T proj ect s are different from t hose encount ered on ot her t ypes of proj ect s. For I T proj ect s t o succeed, for exam ple, it is im port ant t o have t hem support ed by senio r level proj ect sponsors. I T proj ect s wit hout powerful and at t ent ive

sponsors are proj ect s t hat are likely t o encount er a host of difficult ies. Also, because I T proj ect s are concerned wit h convert ing business needs int o t echnical solut ions, proj ect t eam s m ust be com prised of a wide range of players reflect ing bot h t he business and t echnical dim ensions of t he proj ect effort . Charvat also recognizes t hat I T proj ect s m ust conform t o t he syst em developm ent life cycle ( SDLC) . SDLCs have em erged over t he years as ways t o handle t he inherent com plexit y of knowledge- based syst em s. They are t he engines t hat drive t he proj ect , and a key challenge of I T proj ect m anagers is t o plan proj ect s t hat operat e in harm ony wit h t he SDLC. Throughout his book, Charvat discusses proj ect m anagem ent in t he SDLC cont ext . Charvat also acknowledges t hat convent ional proj ect m anagem ent pract ice has a significant role t o play in I T proj ect m anagem ent . I n t he second half of t he book, where he discusses proj ect planning, cont rol, and closure, he reviews st andard proj ect m anagem ent t echniques in t he areas of scheduling and configurat ion cont rol. But even here, he put s an I T spin on t he m at erial, as when he highlight s t he special role of t est ing in soft ware developm ent . This book serves a brid ging funct ion, where best - pract ice I T m anagem ent and convent ional proj ect m anagem ent m erge. By addressing t he special issues associat ed wit h I T proj ect s, it offers I T proj ect m anagers pert inent insight s t hat t hey would not encount er in t he st andard proj ect m anagem ent lit erat ure. J. Davidson Fram e, PhD Dean, Universit y of Managem ent and Technology Arlingt on, VA USA

Pr e fa ce This book is a usable and pract ical approach on t he subj ect of I T proj ect m anagem ent . The t it le of t he book—Proj ect Managem ent Nat ion—w as largely int ended t o illust rat e t he point t hat proj ect m anagers at t im es approach I T proj ect s in sim ilar ways. They could t hus be seen as a nat ion of professionals, irrespect ive of where t hey reside globally. The chapt ers present ed t o you have been carefully st ruct ured and t he int ent is for you t o accom plish t he following goals: first , t o im m ediat ely benefit from t he knowledge, and second, t o apply t his knowledge from a inform at ion t echnology perspect ive. The chapt ers appear in a logical m anner and should be read sequent ially t o gain underst anding of t he concept s and t echniques. By underst anding one chapt er, you will be able t o st art one phase of a proj ect during it s life cycle. By m ast ering all, you will be able t o part icipat e or act ively engage in com plet ing all phases of a proj ect . This book consist s of nine chapt ers t hat are independent , yet all connect ed: §

Chapter 1 : Underst anding Proj ect St rat egy. I am writing this chapt er prim arily for t he proj ect sponsor or execut ive t eam in order t o det ail t he business and I T st rat egy issues, t heir relat ionships t o proj ect s, and, m ore im port ant ly, t he m anner in which proj ect m anagem ent act ually relat es t o t his organizat ional st rat egy. Wit hout a clear st rat egy, it is not apparent why proj ect s are im port ant t o a business, and, as a result , m any proj ect s are eit her cancelled or face bit t er consequences lat er on.

§

Chapter 2 : Becom ing an I T Proj ect Manager. During this chapt er, I ident ify what m akes one proj ect m anager bet t er t han t he next , by evaluat ing t he at t ribut es, charact erist ics, and t ype of person t hat m akes an effect ive proj ect m anager.

§

Chapter 3 : Proj ect Concept s. I consider why a form al life cycle approach works best in t he proj ect m anagem ent environm ent , as m any businesses all have t heir own proj ect m et hodologies and approaches. This chapt er exam ines which one is bet t er suit ed t o a specific proj ect .

Once giving a com plet e explanat ion as t o how t he overall st rat egy drives proj ect m anagem ent , t he book m oves on t o Chapt ers 4 t o 9. These chapt ers focus on what you, as t he proj ect m anager, need t o do wit h your proj ect t eam and st akeholders t o ensure t hat t he proj ect goals are achieved and t hat t he business benefit s are delivered. §

Chapter 4 : The Proj ect Analysis. This chapt er ident ifies and concent rat es specifically on how and when a proj ect act ually

st art s. Do proj ect m anagers sim ply j um p in and run wit h t he proj ect or are t here som e form alit ies t o consider before plan ning t he proj ect ? Wit hin t his chapt er I show t he feasibilit y of a proj ect right t hrough t o t he approval of t he proj ect . §

Chapter 5 : Planning for Success. Planning a proj ect can be dem anding for any proj ect m anager who has never at t em pt ed t o perform such a t ask. This chapt er deals wit h t he basic essent ials of planning a proj ect . Sim ply put , m any proj ect failures t hat occur t oday are due t o failure of planning and est im at ion. This chapt er present s ways t o overcom e t hese failures.

§

Chapter 6 : Execut ing t he Proj ect . I n t his chapt er I present how t o execut e a proj ect wit h t he proj ect stakeholders, not forget t ing t he issues and pit falls t hat need t o be addressed during t his phase.

§

Chapter 7 : Cont rolling t he Proj ect . Cont rolling any proj ect requires essent ial proj ect m anagem ent skills and t echniques. This chapt er exam ines how t o cont rol a proj ect sm oot hly and in a t im ely m anner during t he various proj ect phases.

§

Chapter 8 : I m plem ent ing t he Proj ect . Within this chapter I ident ify and recognize t he m ost im port ant areas of proj ect im plem ent at ion. To im plem ent a proj ect based solely on a gut feeling is not good enough. Most of t he failures t hat occur t oday are failures of im plem ent at ion!

§

Chapter 9 : Closing t he Proj ect . Wit hin t his chapt er I specifically explore t he pract ical requirem ent s and issues t hat need t o be cat ered t o by t he proj ect m anager when com plet ing a proj ect .

This book is int ended t o be of significant int erest t o bot h t he new and pract icing I T proj ect m anagers who are prim arily int erest ed in st art ing a I T proj ect once t hey have been ident ified or have been assigned a proj ect by m anagem ent . Knowing which key areas and t em plat es are needed and underst anding what t o do during each proj ect phase ( wit h t he help of valuable proj ect lessons learned) will go a long way in est ablishing your credibilit y as a proj ect m anager. To avoid any surprise on your part , let m e st at e t hat m y int ent ion wit h t his book was not t o delve int o t he great dept hs of each knowledge area and t echnique ( such as PERTS and Gant t chart s) , but rat her t o supplem ent it from a pract icing perspect ive. I w elcom e any crit ique you m ay have. Let m e conclude by insist ing t hat we who are responsible for m anaging proj ect s m ust do so wit h such uniqueness and diligence as t o ensure t hat proj ect m anagem ent will cont inue t o be seen as t he key different iat or by

which organizat ions want t o deliver product s and solut ions. This publicat ion is based on m y experience, valuable client input , and discussions held wit h fellow proj ect m anagers. The opinions expressed in t his book are t hose of t he aut hor and do not necessarily represent t hose of RCG I nform at ion Technology, I nc. I hope t hat you will enj oy t he m anner in which t his book is present ed, wit h it s logic, useful fact s, findings, and applicat ions for everyday I T proj ect m anagem ent .

Ch a pt e r 1 : Un de r st a n din g Pr oj e ct St r a t e gy PROJECT STRATEGY I N M OTI ON Som et im es all t his t alk of business st rat egy, com pet it ive edge, and t echnology get s a lit t le hard t o digest all at once. I n t he course of m y work as a proj ect consult ant , I not ice on a daily basis how rapidly com put er soft ware and t echnologies change, and it 's get t ing difficult t o keep up. Before you know it , anot her version of soft ware is being int roduced or a newer t echnology is on t he m arket . Today, you can get st at e-o f- the-art soft ware applicat ions t hat can be developed far m o re quickly t han before, allowing organizat ions im proved funct ionalit y and great er opport unit ies. Senior execut ives face t he front line, const ant ly bom barded by soft ware com panies and consult ant s who m arket inform at ion t echnology ( I T) solut ions t hat are able t o revolut ionize and im prove t heir organizat ions. Sadly, not m any of t hese soft ware syst em s get developed or im plem ent ed t o t he ext ent t hat t he client would have liked. The m ost im port ant predict or of an organizat ion's ult im at e success or failure is t he st rat egy t hat it chooses t o adopt . These organizat ions are challenged, as t hey need t o keep pace wit h com pet it ive m arket s, client needs, and m arket place t rends. Winning is basically about who has t he upper hand ( eit her wit h new t echnology or quicker im plem ent at ions) : The only winners will be t hose execut ives who are able t o reinvent t heir com panies quickly enough t o t ake full advant age of t he efficiencies and bet t er dist ribut ion t hat new t echnologies can offer. To overcom e t heir com pet it ion and t o be an indust ry leader, com panies need t o be able t o provide t heir client s t he lat est product s and available services. And proj ect m anagem ent plays an im port ant role in all of t his. However, get t ing t o t he point of int roducing a product or solut ion requires strategic assessm ent and planning, which m ust be done before anyt hing can even com m ence. The senior execut ive t eam wit hin t he organizat ion needs t o com e up wit h a st rat egic plan ( or gam e plan, t o use a sport s m et aphor) before any engagem ent t akes place. Wit hout a strategic plan in place, execut ives can lit erally m ove from one solut ion offering t o t he next , spending m illions of dollars in t he process, wit h t he result being t hat m any proj ect s head sout h. The point , aft er all, is t o m ake sure t he organizat ion is m ore valuable, has a business st rat egy in place, and is ready t o st art wit h t his gam e plan. From proj ect m anagem ent 's point of view, t here is no need t o m anage any proj ect if t he proj ect m anager has no idea why it 's being done in t he first place. I t 's crucial fo r any proj ect m anager t o address t he larger issues of t he business st rat egy and see where t he proj ect fit s in t he overall fram ework. I t isn't easy—but it needs t o be done. The t hought s cont ained wit hin t his chapt er are im port ant , as t hey represent t he

st rat egic concept s and ideas form ulat ed at t he corporat e or business level and t he role of t he proj ect m anager at a lower funct ional or operat ing level. When I address business st rat egy, I am also including t he alignm ent of inform at ion t echnology as an int egral part of t he gam e plan. The reason m ay be t hat com panies t hat are reluct ant t o invest in new t echnologies m ay t herefore never address t heir I T problem s, or worse, are left behind by t heir com pet it ors. Therefore, every organizat ion needs a docum ent ed st rat egy t hat is realist ic and is agreed t o by everyone. Good st rat egy leads t o good result s. Bad st rat egy will not allow an organizat ion t o survive it s com pet it ion. Let m e illust rat e an exam ple of how t echnology and m arket t rends are forcing organizat ions t o adapt t heir business st rat egies t o m eet fut ure I T dem ands. I t is est im at ed t hat by 2005 over 80 m illion people will be sending wireless im ages on t he fly, using num erous digit al devices. Sounds like som et hing from St ar Trek, doesn't it ? I f t his predict ion com es t rue, t hen exist ing net work infrast ruct ures run t he serious risk of becom ing out dat ed, as newer high- speed net works on t he 128 kbps and 384K Tim e Mult iple Access Division ( TDMA) range will be needed t o handle t hese t echnologies. Many com panies will t herefore need t o revise t heir business and I T st rat egies, and proj ect m anagers will be required t o im plem ent t hese result ing new st rat egies ( see Figure 1.1 ) .

Figure 1 .1 : Underst anding proj ect st rat egy

Achieving Com pany St rat egy The first and m ost im port ant st ep in achieving a com pany st rat egy is developing and set t ing in m ot ion a business st rat egy for t he organizat ion. The I T st rat egy t hen form s t he core part of how t o get t here; t herefore, when I T is in volved, t hese st rat egies m ust be verified and discussed at an execut ive level. I f t he overall st rat egy is wrong or t he problem st rat egically m isunderst ood, t he result s are, not surprisingly, less t han sat isfact ory. No am ount of effort or leadership or t act ical brilliance from t he execut ive officers will com pensat e for an incorrect st rat egy. St rat egies are always form ed and execut ed at different levels wit hin any organizat ion. Table 1.1 illust rat es t hose levels where proj ect m anagers cont ribut e t he m ost t o t he overall st rat egy. Ta ble 1 .1 : St rat egy levels w it hin organizat ions St ra t egy La r ge Sm all Business Levels Ent erprises Corporat e Business Funct ional

?/font>

?/font>

Operat ional

?/font>

?/font>

The funct ional st rat egy level refers specifically t o t he gam e plan for a part icular business act ivit y, depart m ent , or business process. The prim ary role of t he funct ional st rat egy is t o support t he com pany's overall st rat egy and com pet it ive approach. The operat ional st rat egy deals wit h how t o m anage cost s, qualit y t arget s, and delivery at t he front line. Many com panies use proj ect m anagem ent t o deliver st rat egic goals and act ions. Com panies are now realizing t hat in t he fast - paced I nform at ion Age, weapons such as speed, opport unit ies, and niches are prized elem ent s in any business arsenal. I n all subsequent chapt ers in t his book, I focus on how proj ect m anagers ensure t hat st rat egy succeeds at bot h t he funct ional and operat ional levels. Clearly, t here is a need t o underst and som et hing about st rat egy aft er all. I nform at ion t echnology is changing at such an am azing rat e t hat , in order for com panies t o survive in t he com pet it ive m arket place, t hey m ust use m ore and m ore solut ions t hat require enhancing exist ing syst em s and decom m issioning older ones. So, t oo, proj ect m anagem ent needs t o fit int o t he overall com pany st rat egic m odel, whereby proj ect m anagem ent is t he area that brings in the I T solut ions ( product s or services) before com pet it ors can react . Applying proj ect m anagem ent and underst anding t he st rat egic int ent of t he com pany j ust ifies m aneuvering t he com pet it ive advant age correct ly, which is all t he m ore im port ant . Proj ect s need t o

bring in solut ions t hat not only are fast er, cheaper, or have a unique, focused cost advant age, but also are able t o serve client s world - wide.

Sun Tzu, a famous military general, once said, “The one with many strategic factors on his side wins....The one with few strategic factors on his side loses. In this way, I can tell who will win and who will lose. “ The proj ect m anager has t o t ake t he slog up t he m ount ain and ask t he proj ect sponsor and ot her st akeholders t ough quest ions such as, "How do we m easure success at t he end of t his proj ect ?", "What do you really want t o buy for all t his m oney we're going t o spend?" To get answers t o t hese quest ions, everyone m ust exam ine t he st rat egic aspect , which st art s at t he very beginning of t he proj ect idea or concept . Wit hout an underst anding of t he desired result , t he proj ect m anager cannot fend off scope creep and define success for t he people who will be doing t he work ( see Figure 1.2 ) .

Figure 1 .2 : Proj ect m anagem ent involvem ent in form ulat ing st rat egies Purpose of St rat egy The purpose of st rat egy is t o provide direct ion and concent rat ion of effort as organizat ions cont inually st rive t o im prove t heir posit ion or gain t he upper hand wit hin t he m arket place. Basically, it 's a st ruggle for advant age, and t he one wit h t he best advant age wins. I t 's t hat sim ple. On what areas m ust businesses concent rat e? Businesses clearly have t o

§

Gain new advant ages t hat increase or im prove cust om er sat isfact ion, which will different iat e t hem from t heir com pet it ors

§

Eit her elim inat e or m inim ize t heir com pet it ors

§

Achieve speed t o m arket

§

Re- engineer business processes for im proved com pet it iveness

§

Align t heir organizat ions t o t he lat est econom ic t rends

§

I m plem ent t he st rat egy ( i.e., t hrough proj ect s)

§

Evaluat e t he success of t he st rat egy ( i.e., m easure proj ect success)

Organizat ions m ust focus on proj ect m anagem ent as t he key business driver t hat will achieve t hese advant ages for t hem . As a profession, proj ect m anagem ent would be able t o support t he overall business st rat egy wit h clear- cut benefit s and advant ages. 1.

Reduce delivery cost s. Proj ect m anagem ent can provide product s and services m ore cheaply by following a st ruct ured and form alized proj ect m et hodology and by ensuring t hat excessive cost s are not spent wit hout due considerat ion.

2.

Enable quicker product t o m arket . The advant age perm it s t he business t o deliver product s or services m ore efficient ly t han t he com pet it ors and t he business is able t o react m ore favorably t o m arket dem ands.

3.

Focus advant age. The proj ect s will be focused m ore on t he client needs and product s, inst ead of having a solut ion t hat does not deliver t he expect ed ret urns.

4.

Produce qualit y deliverables. Proj ect m anagem ent builds qualit y int o t he product s or services right from t he st art , ensuring t hat t he right t hings are developed at t he right specificat ion.

5.

Provide cust om er advant age. Proj ect m anagem ent gains advant ages for t heir organizat ion by working t oget her wit h t he cust om er( s) and by accom m odat ing t heir needs and requirem ent s.

So, t o gain a com pet it ive advant age, execut ives will inevit ably ask cert ain quest ions: ( 1) Do we have t he resources and skills t o gain t he advant age?

( 2) I s it wort h t he effort for us t o do t his? ( 3) How long would it t ake for us t o gain t he advant age? ( 4) Who wit hin our business will t ake charge of leading t he developm ent of a new product or services? ( 5) How com pat ible is t he solut ion wit h t he rest of our exist ing I T port folio? ( 6) How m uch would it cost us t o gain t he advant age? ( 7) What is it t hat we want t o do wit h t he t echnology? St rat egic Leadership All com panies require t hat t he overall st rat egy be driven from t he t op of t he com pany in order for proj ect s t o be successful. The organizat ional execut ive t eam usually provides t he leadership for t he overall business and I T st rat egy. Before any proj ect is even considered, t he execut ive t eam m ust assess and align t he solut ion against t he business and I T st rat egy, before com m it t ing any proj ect resources t o it . Com panies can achieve t his by fo rm ulat ing a st rat egy st eering com m it t ee, which is responsible for deciding on t he priorit y and feasibilit y of each and every proj ect wit hin t he organizat ion. The source of m any failed proj ect s can be t raced t o t he point where corporat e polit ics get s involv ed, and execut ives oft en t hrow big m oney at t echnologies t o solve t heir problem s. Proj ect m anagers are accordingly assigned t o such proj ect s, and, event ually, t hey fail. The I T proj ect should t herefore com plem ent t he overall business st rat egic plan. Once t he st eering com m it t ee has deem ed t hat t he st rat egy is sat isfact ory, t he following t act ics m ay be necessary t o im plem ent t his st rat egy:

§

Execut ives m ay need t o est ablish alliances or cooperat ion agreem ent s wit h ot her businesses or com pet it ors. Synergy is t he nam e of t he gam e here. The sum is great er t han t he part s. I f st rat egic alliances are form ed, t he proj ect m anager will need t o work across all environm ent s and consider using soft skills such as ( 1) people m anagem ent , ( 2) negot iat ion, ( 3) present at ions, ( 4) diplom acy, and ( 5) t act .

§

Addit ionally, organizat ions oft en need t o reshape t heir st ruct ures t o accom m odat e subt le changes t o alreadyest ablished st rat egies. This is why it is so com m on t o read about com panies rest ruct uring in t he business m edia.

§

Organizat ions need t o have available resources ( i.e., proj ect m anagers, facilit ies, et c.) t o execut e t he various proj ect s t hat have been ident ified as a result of t he st rat egy work session. Som et im es, at t em pt ing t oo m any proj ect s all at once in an effort j ust to rem ain com pet it ive can result in failure. An exam ple of t his is t rying t o int egrat e m ult iple I T proj ect s concurrent ly wit h an exist ing billing syst em . I t is bet t er t o

im plem ent a few successful proj ect s inst ead of several proj ect s, m any of which m ay not succeed. Execut ive Responsibilit ies Ult im at ely, t he core funct ions of execut ives are t o craft , im plem ent , and execut e st rat egy. Period. They craft st rat egies in order t o ( 1) shape t heir com pany's course of act ion and ( 2) coordinat e a com pany-wide gam e plan . Proj ect m anagers should obt ain t he approval and "go - ahead" of t he execut ive t eam for all I T proj ect engagem ent s, t hus ensuring t hat t he appropriat e processes for t he delivery of t he business and I T have been scrut inized, reviewed, and priorit ized. Execut ives and proj ect m anagers should agree on t he following obj ect ives:

§

Alignm ent of t he proposed I T invest m ent plan ( i.e., proj ect s) wit h t he com pany business obj ect ives;

§

Com m it m ent t o delivery of m easurable business benefit s wit hin schedule, cost , and risk t hat are realist ic and appropriat e t o t he business;

§

A shared underst anding of t he responsibilit ies for delivery of t he proj ect bet ween syst em users and t he I T specialist s;

§

A plan t o benchm ark t he perform ance of exist ing processes in business t erm s and t o t rack im provem ent s;

§

Risk m anagem ent t hat recognizes t he need t o accom m odat e change.

I t is com m on pract ice in m any com panies t o appoint bot h a business proj ect m anager and a m arket ing m anager t o deliver t he business benefit s and t o appoint an I T proj ect m anager t o deliver t he inform at ion syst em or solut ion. These m anagers should be held account able t o t he com pany for t he success of t he proj ect . I n com panies wit h an on- going I T invest m ent program , t he execut ive t eam should ensure t hat t hese processes are being syst em at ically planned, execut ed, and reviewed. Underst anding Proj ect , Program , and Operat ions Today, t he m aj orit y of client s require proj ect m anagers t o form ulat e t he concept ual t hinking necessary for planning t he ent ire proj ect . Not t oo surprisingly, t he inclinat ion of m ost proj ect m anagers is t o skip t he st rat egic phase of proj ect m anagem ent and t o st art t he proj ect . I t is essent ial t hat proj ect m anagers underst and t he key differences bet ween how com panies do business, in order t o best achieve project success ( see Table 1.2 ) .

Ta ble 1 .2 : Uniquenesses bet w een operat ions proj ect and program m anagem ent Operat ion Proj ect Program Managem ent Mana gem ent Managem ent Repeat ed

Unique

Can be bot h

Continuous

Tem porary

Can be bot h

Evolutionary

Revolut ionary

Can be bot h

St able resources

Varying Resources

Can be neit her

Focus on product s

Focus on Product s

Focus on benefit s

Focus on Solut ions W hat are St rat egic Proj ect s? Where t he proj ect is a com ponent of a broader business sense, it should be assessed as an int egral part of t he st rat egic program . All t he norm al financial assessm ent rules should be applied. The execut ive t eam should pay close at t ent ion t o t hose part s of t he proposed solut ion t hat clearly show t he benefit s of proceeding wit h t he solut ion. Managers should ensure t hat det ailed plans for achieving t he benefit s, and specific responsibilit y for delivering t hem , are in place. I T planning m ust t ake account of t he int ended direct ion of t he business, financial const raint s and crit eria, and hum an resource ( HR) plans and policies. I t m ust also be flexible enough t o cope wit h any likely response from com pet it ors over t he whole proj ect life cycle. Proj ect m anagers should have a clearly com m unicat ed policy for t he way t o collect , use, and st ore inform at ion in support of t he business obj ect ives and t he way t he syst em s will enable t hem t o harness t he value of t his inform at ion in t he fut ure. Translat ing St rat egy int o Proj ect s Once t he st rat egy has been det erm ined and has been approved by t he com pany execut ive t eam , t he responsibilit y of t he proj ect success does not fall only at t he feet of t he proj ect m anager. The chief execut ive officer ( CEO) , chief inform at ion officer ( CI O) , direct ors, funct ional m anagem ent , and st aff all have specific t angible and int angible roles in t he proj ect . I n t his m anner, m ut ual expect at ions can be m et and benefit s realized. For a successful t ransit ion from st rat egy t o proj ect , t he business m ust have in place

§

Agreem ent on what needs changing, and why ( t his should be clearly support ed by t he proj ect sponsor) ;

§

A com m on "language" for analyzing and describing requirem ent s, based on a shared underst anding of t he business processes across "client ," purchasing, and inform at ion syst em s ( I S) depart m ent s ( don't assum e t his is t he case) ;

§

Agreed processes t hat involve t he users in t he select ion and design of syst em s solut ions ( consider m aking a "client ," rat her than an I S specia list , t he program m anager responsible for delivering t he business benefit s) ;

§

The support of a skilled, experienced t echnology proj ect m anager.

Each and every proj ect should have som e sort of a m ission. The m ission ident ifies t he client 's requirem ent s and clearly defines t he purpose of t he proj ect . A proj ect 's m ission m ust be com plet ed for success of t he proj ect . Obj ect ives define t he success crit eria for t he proj ect . The obj ect ives relat e direct ly t o t he com plet ion of t he proj ect 's m ission. Com plet ing all of t he obj ect ives should accom plish t he proj ect 's m ission. Measurable obj ect ives provide a m et hod of quant ifying t he result s and est ablishing qualit y st andards t o evaluat e t he success of t he proj ect . Figure 1.3 illust rat es t he need for st rat egic t hinking on a t ypical proj ect .

Figure 1 .3 : The basic beginnings of st rat egy on a proj ect life cycle St rat egic Requirem ent s I t is essent ial t hat t he result s of t he proj ect analysis be capt ured, as a form al expression of business needs. Specifying business requirem ent s from a st rat egic perspect ive is not easy and it dem ands considerable skill, creat ivit y, and breadt h of vision. Addit ionally, having t he necessary experience and knowledge of t he specific business environm ent assist s execut ives in form ulat ing t he st rat egy. I f t his cannot be perform ed, m anagers m ay want t o consider using an independent , obj ect ive t hird

part y t hat has dem onst rat ed it s capabilit y in prior st rat egy engagem ent s. This t hird part y is basically brought in by an execut ive t eam t o facilit at e and help docum ent business requirem ent s. There are significant advant ages t o t his, and m any organizat ions are even working in t his way wit h st rat egic alliance part ners as well. I t encourages shared- risk and partnership - st yle relat ionships. The m aj orit y of com pany st aff will have a lim it ed underst anding of business st rat egy ( let alone I T st rat egy) as it is a difficult art t o m ast er. The following suggest ions will assist execut ives and proj ect m anagers alike in at t aining som e perspect ive on st rat egy. •

At t end conferences and sem inars on st rat egy.

•

Join professional associat ions.

•

Read publicat ions on st rat egy.

•

Have a m ent or.

•

St udy and pract ice.

Senior Managem ent Com m it m ent A m ut ually accept able com m it m ent bet ween a proj ect sponsor and a proj ect t eam m ust exist before a viable proj ect exist s. A proj ect sponsor is a knowledgeable person who represent s t he event ual owner of t he product of t he proj ect and who is responsible for providing t he necessary resources ( m oney, goods, services, and general direct ion, as appropriat e) . A proj ect t eam is a knowledgeable and qualified group able and willing t o undert ake t he work of t he proj ect . A m ut ually accept able com m it m ent is one in which t here is agreem ent on t he goals and obj ect ives of t he proj ect in t erm s of t he product 's scope, qualit y grade, t im e t o com plet ion, and final cost . Effect ive and efficient policies and procedures m ust be in place for t he conduct of t he proj ect com m it m ent . Such policies and procedures m ust cover, at a m inim um , clear roles and responsibilit ies, delegat ion of aut horit y, and processes for m anaging t he scope of work, including changes, m aint enance of qualit y, and schedule and cost cont rol. Execut ive Requirem ent s on St rat egy Proj ect m anagers need t o realize t hat execut ives wit hin organizat ions are big on m aking t hings happen. Wit hout a doubt , t hey are t ot ally result sorient at ed. Due t o t heir posit ions ( i.e., CEO, CI O, direct or, et c.) t hey are held account able t o t heir shareholders for "result s." Because of t his, execut ives t end t o ident ify and focus on t hose proj ect s t hat cont ribut e t o t he following:

•

Keeping t he shareholders happy

•

I ncreasing t he m arket share

•

Raising revenues

•

At t ract ing new client s

•

Getting higher dividends

•

Lowering any operat ional expenses

•

Increasing t he efficiency in t he com pany

•

I ncreasing repeat client visit s

•

Lowering t he cost of sales

•

Making workers m ore product ive and having a sat isfied em ployee workforce

Therefore, execut ives are big on specific, dem onst rable progress and m easurable result s, and if proj ect m anagers cannot guarant ee any visible ret urn on t hese fact ors, t hey can m ore t han likely expect m inim al sponsorship on t heir proj ect s and even a dip in t heir careers. Underst anding t he Cult ural Environm ent An inform ed m anagem ent m ust pro vide a support ive cult ural environm ent t hat will enable t he proj ect t eam t o produce it s best work. An inform ed m anagem ent is one t hat underst ands t he proj ect m anagem ent process. A support ive cult ural environm ent is one in which t he proj ect is clearly backed by execut ives and m anagem ent ; it is also one t hat allows proj ect t eam s t o produce t heir best work wit hout unnecessary bureaucrat ic hindrance. Following t his principle m eans t hat execut ives and m anagem ent need t o align t he proj ect m anager's leadership and m anagem ent st yle t o bot h t he t ype of proj ect and it s com plexit y. The Proj ect Chart er The proj ect chart er is developed as a precursor t o t he com m encem ent of form al act ivit y relat ing t o a proj ect . I t t ook m e m any years t o fully underst and what t he act ual purpose of t he proj ect chart er was. I t represent ed yet anot her process docum ent —an adm inistrative burden. I t seem ed t o m e t hat I was m erely duplicat ing proj ect inform at ion in virt ually every single docum ent I was producing. Surely, I only needed a proj ect plan t o gain approval for t he proj ect . The chart er is basically prepared in order t o describe, t o execut ive m anagem ent , t he requirem ent s and overview for t he proposed proj ect , and it is t he prim ary docum ent used by execut ive m anagem ent t o

approve t he necessary resources ( work - hours and budget ) for t he pending proj ect . The bot t om line is t hat even if t he proj ect is short in lengt h, develop a chart er. I t gives som e credibilit y t o t he upcom ing proj ect and also gives t he writ er of t he chart er credibilit y as t he chosen proj ect m anager. These people are t he people who endorse t he proj ect . I sn't it am azing how m uch m ore sm oot hly a proj ect flows wit h an execut ive on board! Wit hout a proj ect chart er, st aff t hroughout t he com pany will never be able t o see t he im port ance of t he proj ect in t he sam e light as t he proj ect m anager does, due t o t he fact t hat t hey are uninform ed and t hey are oft en uncert ain as t o who is support ing t he effort . This proj ect m ay appear t o be j ust anot her one t hat is t aking place. However, if t he com pany is aware of t he CEO's com m it m ent t o t he proj ect , t he proj ect m anager will be am azed at t he posit ive react ion and response received during t he ent ire proj ect process. When t he proj ect chart er has been com plet ed, t he ideal sit uat ion is for t he proj ect m anager t o personally deliver t he proj ect chart er t o t he execut ive's office for approval. Once t he chart er has been delivered, t he proj ect m anager should m ake a call t hree days aft er t he execut ive get s t he proj ect chart er, in order t o follow- up on progress. That allows one day for t he chart er t o go t hrough t he execut ive's int ernal m ail syst em and t wo days for t he execut ive t o review t he chart er. By personally get t ing involved, t he proj ect m anager shows a com m it m ent t o t he proj ect and dem onst rat es a posit iv e approach t o t he process ( see Figure 1.4 ) .

Figure 1 .4 : The originat ion of t he chart er

Effect ive Com m unicat ion Many proj ect s are inst igat ed from t he t op down and proj ect m anagers are accordingly appoint ed t o t ake charge of a proj ect . Senior execut ives rarely m isguide st aff, are very up- front , and would rat her not see t he proj ect m anager wast ing anyone's t im e in t heir com pany. Therefore, a dynam ic com m unicat ion channel should exist bet ween t he proj ect spo nsor and t he proj ect m anager for all decisions affect ing t he proj ect . I have found t his t o be t he m ost powerful way of achieving proj ect success. This principle is necessary for t he effect ive and efficient adm inist rat ion of t he proj ect com m it m ent . The project m anager m ust have t he skills, experience, dedicat ion, com m it m ent , aut horit y, and t enacit y t o lead t he proj ect t o success, and m ust know how t o deal wit h execut ives on t he proj ect level. Mot ivat ing senior execut ives t o underst and t he need for t he proj ect m ay not be for everyone! But one t hing is cert ain: The proj ect m anager should

be t he single point of cont act , bot h for subm it t ing t he proj ect for review and negot iat ing it s approval—not anyone else! I f t he proj ect m anager cannot present and com m unicat e t he proj ect at an execut ive level, t hen som eone else should be running t he proj ect . I f a proj ect m anager is able t o com m unicat e well, t hen he or she has a great shot at a fant ast ic career in proj ect m anagem ent .

DEVELOPI N G TH E STRATEGI C PLAN The following sect ion lays out a st rat egic plan for a soft ware com pany. I t reviews st rengt hs, weaknesses, opport unit ies, and t hreat s ( known collect ively as "SWOT") ; A t echnique which allows proj ect st akeholders t o list im port ant or significant areas relat ing t o t he project ; present s a series of st at em ent s relat ing t o t he com pany's vision, m ission, values, and obj ect ives; and set s out it s proposed st rat egies and goals t hrough proj ect m anagem ent . This form at is t ypical. Developing t he St rat egic SW OT Analysis

Table 1.3 shows a st rat egic plan t hat addresses t he following key st rengt hs, weaknesses, opport unit ies, and t hreat s for Com pany xx, I nc. Ta ble 1 .3 : Com pany xx, I nc., SW OT analysis St rengt hs

W ea k nesses

Key client acquired

Lack of awareness about prospect ive client

I nit ial solut ion can evolve int o range of offerings

Need addit ional I T st aff for delivery t eam

Locat ed near a m aj or corporat e HQ

Em ergin g new t echnologies

Very focused m anagem ent / st aff

Need aggressive account execut ive placed at client

Opport unit ies

Threa t s

Client owns m any com panies— diverse m arket s

Could at t ract m aj or com pet it ion

Possible off- shore developm ent

Econom y turbulent —affecting sales of I T syst em s Em erging t echnology could t hreat en solut ion

Vision The vision for Com pany xx, I nc., in t wo years t im e is: Com pany xx, I nc., will have annualized sales of $30 m illion and be profit able. I t will em ploy 2,000 consult ant s who are m ainly engaged in Esolut ions, m arket ing, sales, and proj ect m anagem ent . Com pany xx, I nc., will offer five core solut ions and provide added- value services t o a large client base t hroughout t he cont inent al Unit ed St at es and t wo count ries overseas. Our solut ions will be t echnically advanced and will be t ailored where necessary t o offer advant ages and im provem ent s over our com pet it ors' possible offerings. We will cont inue t o expand t hrough organic growt h and acquisit ions in relat ed t echnology and m arket segm ent s. M ission St at em ent The prim ary focus of Com pany xx, I nc., is defined as: We will design, develop, and m arket advanced E- solut ions for our client s. These web- based syst em s work wit h specialist hardware supplied by m aj or int egrat ors. Our solut ions are dist inguished from our com pet it ions' by t heir sophist icat ed int erfaces, scalabilit y, and ease of m odificat ion and im plem ent at ion. Sales are m ade direct ly and t hrough our Sales and Market ing channels est ablished in t he cont inent al Unit ed St at es and overseas m arket s. Corporat e Values The corporat e values governing developm ent will include t he following: §

Com pany xx, I nc., operat es in accordance wit h t he highest st andards in all relat ionships wit h client s, suppliers, t he environm ent , and t he com m unit y.

§

Com pany xx, I nc., fost ers a clim at e t hat encourages innovat ion and diligence am ong st aff and rewards accordingly.

Business Obj ect ives Longer- t erm business obj ect ives of Com pany xx, I nc., are sum m arized as §

Expanding t he business aggressively and offering aboveaverage ret urns t o shareholders

§

Becom ing t he leading innovat ive e- solut ions com pany wit hin t he five core solut ions areas

Ke y St r a t e gie s Com pany xx, I nc., will pursue t he following crit ical st rat egies: •

Ext end t he current core t echnical solut ion areas.

•

I ntensify senior m anagem ent t eam in sales/ m arket ing.

•

St rengt hen hum an resources funct ion and develop a Career Developm ent Program .

•

Seek new m arket segm ent s for solut ions.

The com pany will also pursue t he following im port ant st rat egies: •

Start participating in int ernat ional t rade shows and act ivit ies.

•

Develop overseas m arket ent ry plans.

•

Pursue st rat egic alliances wit h our core t echnologies.

•

St rengt hen and prom ot e web presence.

•

Seek new m arket segm ent s and applicat ions for our solut ions and services.

M aj or Goals The following key t arget s will be achieved by Proj ect ABC over t he next t wo years: •

Achieve I T solut ion sales of $9 m illion by 200X.

•

Report annualized profit s of $2.5 m illion in 200X.

•

Est ablish Com pany xx t o be t he largest solut ion provider by 200X.

•

Beco m e largest supplier of cust om ized I T syst em s in four count ries wit hin 200X.

•

Em ploy 200 t echnically qualified I T st aff by 200X.

St ra t egic Act ion Progra m s The following st rat egic act ion program s will be im plem ent ed:

•

CEO and President will, wit hin five m ont hs, prepare com prehensive business plan.

•

Chief finance officer ( CFO) will, wit hin t hree m ont hs, int roduce an im proved cost report ing solut ion.

•

Market ing senior vice president will, wit hin six m ont hs, im plem ent new client relat ionship m odel t o st rengt hen sales and m arket ing funct ion in all xx st at es.

•

Solut ions senior vice president will, wit hin six m ont hs, ident ify and align com pany solut ions t o indust ry dem ands and pursue t echnical alliances.

•

Regional account m anagers will, wit hin t wo m ont hs, develop and im plem ent accelerat ed m arket ent ry and will develop plans of product s and services.

DEVELOPI N G TH E PROJECT STRATEGY The success of any proj ect is achieved by ensuring t hat t he correct st rat egy and focus have been assigned t o t he respect ive proj ect . Many com panies fail t o ident ify and priorit ize t heir proj ect s properly. The result is t hat no one assesses t he com pany port folio of proj ect s, and m any proj ect s fail because of t hat . Som e key elem ent s t hat need t o be addressed when st rat egizing and aligning proj ect s t o t he overall business are •

Underst anding t he need for t he proj ect

•

Ensuring t he com pany st rat egy is correct ly aligned t o t he proj ect

•

Finding t he right sponsor or cham pion for t he proj ect

•

Having a proj ect chart er

•

Being able t o fund t he proj ect

Figure 1.5 represent s a t ypical list of proj ect s wit hin a com pany. I t is essent ial t hat a priorit y list be developed for t he senior execut ive level prior t o any proj ect com m encing.

Figure 1 .5 : The priorit izat ion o f your proj ect portfolio Sun Tzu said When your st rat egy is deep and far reaching, t hen what you gain by your calculat ions is m uch, so you can win before you even fight . When your st rat egic t hinking is shallow and near- sight ed, and t hen what you gain by your calculat ions is lit t le, so you will lose before you do bat t le. Much st rat egy prevails lit t le st rat egy, so t hose wit h no st rat egy cannot help but be defeat ed. Therefore it is said t hat vict orious warriors win first and t hen go t o war, while defeat ed warriors go t o war first , and t hen seek t o win.

I W ish I Had Know n That I t is oft en im port ant t o underst and where ot her proj ect s went wrong in order t o avoid facing t hose problem s again. To bet t er ensure t he success of a proj ect , t he proj ect m anager should rem ain aware of t he following issues:

§

The delivery of business benefit s m ust rem ain a senior- level priorit y t hroughout t he proj ect .

§

Rem ain focused on m easuring t he business im provem ent s— m easuring can m ake t hem happen.

§

Benefit s com e from exploit at ion by t he syst em owners and users. Allow enough t im e t o prepare and t rain t hem , or t hey will not be able t o exploit t he syst em effect ively.

§

Proj ect m anagers should recognize t hat , in addit ion t o t he expect ed benefit s, t hey need t o allow for ot her benefit s t o em erge, as t he capabilit y of t he new syst em becom es bet t er underst ood.

§

I nst alling a new solut ion achieves not hing on it s own. Do not expect t he supplier t o deliver t he business benefit s.

§

At t he end of each proj ect , conduct an independent review t o confir m t hat planned benefit s have been realized and t hat t he lessons learned are recorded and applied t o fut ure proj ect s.

§

Focus on t he business benefit s, t hen t he t echnological ones.

§

Proj ect m anagers should only approve proj ect s when t hey are confident t hat t he proj ect s support business obj ect ives, and t hey should t hen m ake t he support public. Senior m anagem ent sponsorship is vit al.

§

Plan t o achieve m easurable im provem ent s.

§

Don't "leave it t o t he professionals." I f a proj ect m anager delegat es responsibilit y for t he m anagem ent of a proj ect or program , it m ust be t o som eone who is account able t o t he Board for delivering t he business benefit s.

§ §

Plan sufficient resources for t raining. Review proj ect s t o confirm t hat planned benefit s are being realized.

LESSON S LEARN ED FOR UN DERSTAN DI N G PROJECT STRATEGY Lessons learned t hat apply t o business st rat egy fall int o t he dom ain of t he senior execut ives, as m ost st rat egic decisions are m ade wit hin t his group. Som e of t he im m ediat e lessons execut ives m ay learn include t he following:

§

CEOs insist on a proj ect being carried out because t hey want it done. These approaches are oft en successful; however, t here are j ust as m any proj ect s t hat fail t o get off t he ground, as t hese proj ect s oft en consum e vast resources and are not in t he com pany's st rat egic port folio.

§

St rat egy-m akers at all levels should rem em ber t hat t hey are on t he sam e t eam .

§

Businesses should analyze and fully underst and t he im plicat ions of t he int roducing new I T syst em s for t heir organizat ions.

§

Maj or I T syst em s cannot be int roduced in isolat ion from wider changes t o t he business; t herefore, it is essent ial t hat businesses t horoughly analyze t he im plicat ions of im plem ent ing a new I T syst em . Failure t o m anage change is likely t o result in I T syst em s t hat do not m eet business requirem ents or in delays in im plem ent ing key operat ions. I t m ay also m ean t hat business users are unable or unwilling t o obt ain t he m ost from t he syst em . I nt roducing new syst em s should be based on clear business requirem ent s. Analyzing and writ ing a good st at em ent of business needs requires a wide underst anding of t he business, it s processes, t he support ing inform at ion flows, and fut ure business needs. The business requirem ent specificat ion m ust include im plem ent at ion and operat ional needs. I t is not always possible t o specify fully t he requirem ent s in advance—a well- planned proj ect should be able t o t ake advant age of requirem ent s and capabilit ies as t hey are discovered, provided t hat t hey are j udged relevant t o t he core business obj ect ives and do not increase risks disproport ionat ely.

St rat egy Com plet ion Check list The proj ect sponsor should ensure t hat t he following core docum ent at ion or deliverables are filed wit hin a m ain proj ect folder in order t o com plet e t he st rat egic phase:

§ § § § § §

Proj ect priorit izat ion schedule, which list s all priorit y proj ect s Market ing m at erial in support of concept Business and I T st rat egic plans Execut ive report s Minut es of t he m eet ing aut horizing proj ect decision Any correspondence relat ing t o t he proj ect

Ch a pt e r 2 : Be co m in g a n I T Pr oj e ct M a n a ge r OVERVI EW We'd all like t o be like Tiger Woods or Ernie Els, but we're not , so m y answer t o you is t o get over it . The best we can do is t o hit our drive in t he fairway, knock an iron shot in t he m iddle of t he green, m ake som e put t s, and keep grinding away. Who knows where t he pract ice will t ake you? The sam e applies t o proj ect m anagem ent . I 'm a huge fan of proj ect m anagem ent as a business m anagem ent discipline—all it s t echnologies, processes, t echniques, skillset s, t ools, and annual conferences m ake it one of t he m ost excit ing j obs in exist ence t oday. Call it com m on m anagem ent sense, or what ever you like, it really is a rich and rewarding profession. Chances are you'll enj oy it and t urn out t o be a great proj ect m anager. However, lose t he idea t hat being a proj ect m anager is a walk in t he park. I t 's not . You don't sim ply put a m anager behind som e proj ect m anagem ent soft ware t hat you bought from som e very fam ous com pany. Lose t he idea t hat it 's an easy undert aking. I t 's a slog up a m ount ain. I t is dirt y, hard work, and it is absolut ely necessary. By working hard at specific proj ect s, you will event ually becom e m ore and m ore proficient and knowledgeable at running proj ect s. The following sect ion shows an analogy for t he proj ect m anagem ent experience. For cent uries, m ount ain people of t he Him alayas ( called Sherpas) have navigat ed t he ext rem e condit ions of t he Khum bu region in Tibet , near Mt . Everest . I n 1953, aft er a dozen failed at t em pt s, a Sherpa nam ed Tenzing Norgay becam e one of t wo m en ever t o reach t he sum m it of Mt . Everest , known in Tibet as "Goddess Mot her of t he World." To t his day, Sherpas are enlist ed for t heir unique knowledge of t he t errain and com m and of t he high alt it ude. Their experience helps clim bers t he world over reach t he sum m it . Sim ilarly, proj ect m anagers are oft en faced wit h incredible barriers t hat seem im possible t o overcom e—eit her due t o t echnology or proj ect com plexit y—t hat can be bridged by using skilled m ent ors and experienced proj ect m anagers who have navigat ed t hese knowledge areas before. PROJECT MAN AGER —TREN DS I expect ed a cert ain, sudden expansion and flow of I T proj ect m anagers t o rise, t sunam i- like, by t he t im e t his book was finished. No such t hing. Good proj ect m anagers are hard t o find. However, one t rend is certain: Just before one proj ect has been successfully im plem ent ed, changes are already being m ade on t hat proj ect and anot her proj ect release is in t he planning. I sn't t hat frust rat ing? There are already m ore proj ect s t han t here are proj ect m anagers and it is m ind- boggling how m any proj ect s

are becom ing m ore t echnologically advanced and int egrat ed t han ever before. What a challenge we are all faced wit h t oday! Proj ect m anagers ( including bot h t hose new t o t he profession and exist ing ones) have t o be able t o deliver proj ect s successfully. Sufficient t o say, proj ect m anagem ent is one of t he m ost sought aft er professions in t he world t oday. Organizat ions select people t o m anage proj ect s based on t heir high levels of personal product ivit y and t heir abilit y t o get t hings done. These proj ect m anagers are t ypically t ask- orient ed people wit h a st rong sense of urgency and a keen focus on get t ing st art ed and finishing. All t ypes of indust ries are adapt ing t o t he changes in t echnology and, accordingly, do not hire people wit h t he necessary skills in proj ect m anagem ent which can deliver t hese new proj ect s. The funct ional line m anagers are oft en not considered, as t hey are fam iliar wit h operat ional business issues and are not always suit ably skilled t o work across organizat ional boundaries. Proj ect s t oday need t o be m anaged by people not only wit h t he knowledge of proj ect m anagem ent , but also wit h t he right st uff! I n t his chapt er I illust rat e and address what t he "right st uff" is and t he pat h t o becom ing a proj ect m anager. Client s expect proj ect m anagers t o be com pet ent and be able t o deliver solut ions, irrespect ive of t he com plexit y. At it s sim plest approach, proj ect m anagem ent is very basic. I t is very m uch like any ot her kind of m anagem ent , which covers general m anagem ent pract ices such as planning, organizing, direct ing, and cont rolling. Proj ect m anagem ent , however, concent rat es on addit ional disciplines, such as int egrat ion, risk, com m unicat ions, t im e, and m any ot her relevant aspect s t hat are required t o effect ively deliver a proj ect on schedule, cost , and qualit y. A colleague once asked m e if proj ect m anagers were really needed, as current m anagem ent was already in place. I t hink an answer t o t hat would have been t hat even t he world's best soccer t eam st ill needs a t eam capt ain t o lead t hem . Proj ect m anagem ent uses a com m on set of processes and st andards, which are ut ilized t hroughout any proj ect . The t rend is t hat proj ect m anagers have t o be able t o cope wit h const ant ly changing t echnologies and m et hodologies, w hich if ignored can result in a proj ect becom ing obsolet e or full of changes before it is even com plet ed. Proj ect m anagers in t he I T indust ry t oday, however, are faced wit h having t o keep pace wit h an ever- increasing t echnology t hat changes at a very rapid rat e. These fact ors cont ribut e t o t he im port ance of choosing t he appropriat e person leading t he proj ect . My experiences, as bot h consult ant and pract icing proj ect m anager, have led m e t o realize t hat t oday's proj ect m anager needs a sim ple, yet pract ical approach t o m anaging proj ect s ( see Figure 2.1 ) .

Figur e 2 .1 : The elem ent s of proj ect m anagem ent Proj ect Sponsor Responsibilit ies The proj ect sponsor, in t aking on t he role, accept s overall account abilit y t o t he organizat ion for achieving t he proj ect goals. The proj ect sponsor is, in realit y, t he boss. The sponso r is t ypically a senior person wit hin t he organizat ion who has a high im pact on t he business, has t he necessary experience relat ing t o t he proj ect being undert aken, or has t he organizat ional abilit y t o m ake t hings happen. The sponsor could also hold t he t it le of senior m anager, direct or, CEO, or CI O. The sponsor sees t hat t hings get done in ways t hat would norm ally t ake t he proj ect m anager forever and a day t o com plet e. The sponsor also reviews t he overall progress of t he proj ect and serves as t he source of support if t here are conflict s. The individual who assum es t he role of proj ect sponsor would be responsible for

§ § § § § § §

Select ing t he proj ect m anager Est ablishing t he proj ect goals Providing leadership for t he overall t eam Selling t he proj ect t o st akeholders Resolving crucial risks and issues, if t he proj ect m anager cannot resolve t hem Ensuring t hat t he proj ect m anager is com m unicat ing progress and following t he best approach Ensuring t hat approval is provided t o proceed t o t he next proj ect phase

§ § § §

Approving m aj or proj ect changes ( t oget her wit h t he Change Cont rol Board ( CCB) ) Providing overall direct ion for t he proj ect Pot ent ially assist ing in obt aining valuable resources when t he proj ect dem ands it Assist ing t he proj ect m anager wit h appraisal and perform ance report ing

Before t aking on t he role of proj ect sponsor, t here are som e key quest ions t hat t he ident ified individual needs t o ask him - or herself and ot hers, as an assessm ent and personal com m it m ent will be necessary. Table 2.1 ident ifies a brief "accept ance checklist " used on an I T proj ect . Ta ble 2 .1 : Typical proj ect sponsor accept ance check list Accept ance List for Proj ect Sponsor

Ye s

The proj ect is already underway and is in bad shape.

?/font >

I have the available t im e t o dedicat e m yself t o being a proj ect sponsor.

?/font >

I will enforce unfavorable decisions where needed t o guide t he proj ect forward.

?/font >

No

Unsure

?/fon t>

I w ill place t he proj ect on hold or cancel t he proj ect if appropriat e. Success is possible by int erfacing wit h t he proj ect m anager/ t eam .

?/font >

I will be able t o sell t he proj ect t o st akeholders where required.

?/font >

Ta ble 2 .1 : Typical proj ect sponsor accept ance check list Accept ance List for Proj ect Sponsor I am able t o m ot ivat e and pursue t he necessary resources for t he pr oj ect . ACCEPTAN CE SCORE

Ye s

No

Unsure

?/fon t>

5

1

1

Based on t he accept ance score of 5 in Table 2.1 , t he proj ect sponsor is able t o see t hat t he m aj orit y of issues can, in fact , be agreed upon, and t hat t he role of proj ect sponsor is accept able. For t he t wo it em s t hat rem ain unresolved, t he proj ect sponsor m ust ensure t hat a m echanism be est ablished t hat will allow t hese it em s t o be perform ed by t he sponsor or delegat ed represent at ive. I DEN TI FYI N G TH E PROJECT M AN AGER During t he past few years I have oft en encount ered proj ect m anagers t hat are well qualified but lack t he necessary skills for leading a proj ect . Proj ect m anagers have t o be m ore t han j ust qualified and appoint ed t o t he posit ion of proj ect m anager. The profession not only ent ails fam iliarizing oneself wit h key knowledge areas and being cert ified, but also having t he pract ical abilit y t o get by on t he j ob. Today, t he art of proj ect m anagem ent covers so m any fields t hat t he proj ect m anager st art s wearing m any hat s in a variet y of disciplines: Proj ect m anagers are unique and m ult iskilled, in t hat t hey are able t o funct ion in alm ost any environm ent . The first prerequisit e is t o have a solid underst anding of proj ect m anagem ent . What m akes a good proj ect m anager? I n m y personal experiences I have found t hat proj ect m anagers wit h t he good leadership skills who work well wit h people cont ribut e hugely t o a proj ect 's overall success. I am always so fascinat ed when I see how ot her people would do under sim ilar circum st ances. During t he writ ing of t his book, I observed a colleague of m ine who m anages about $15 m illion a year in I T proj ect s and m anages up t o fift y I T st aff. He gained success largely due t o his abilit y t o build st rong relat ionships wit h all his client s and proj ect t eam s. The client s absolut ely enj oyed having him around. He com m anded a loyal net work of repeat client s and successful proj ect s. I est im at e t hat out of all his proj ect s, sixt y percent cam e from repeat business and leads and fort y percent were from loyal referrals. I was int rigued t o find out what

his secret was, so I redoubled m y effort s on assessing t he t hings t hat he did well. They include t he following t rait s: •

He was ent husiast ic and opt im ist ic about all his proj ect s.

•

He had excellent relat ionships wit h all his client and proj ect st aff.

•

He knew how t o work wit h people and showed his appreciat ion for good work on his proj ect .

•

He knew what was expect ed from him and was dynam ic in m oving forward wit h t he next series of t asks.

Proj ect Manager Select ion and Appoint m ent The proj ect sponsor should form ally appoint a proj ect m anager as early as possible, before t he init iat ion phase of t he proj ect , and not leave t he proj ect unt il aft er t he it has begun. For m ost proj ect s it is unlikely t hat t he proj ect m anager will be som eone who works for t he com pany. The longer it t akes t o appoint a proj ect m anager t o a proj ect , t he m ore likely t he chances are of having schedule slippage problem s. The reasoning is t hat m ost proj ect m anagers are brought on board t oo lat e, and t hey require som e t im e t o becom e fam iliar wit h t he t echnical and proj ect requirem ent s. This set back im pedes t he ent ire effort . So m any proj ects st art wit hout any form al proj ect process or involvem ent of a proj ect m anager. The reason is t hat t hese t ypes of proj ect s are st art ed by eit her t he m arket ing or business depart m ent s wit hin organizat ions. Appoint ing proj ect m anagers is ext rem ely difficult ; one m anager is, sim ply put , m ore product ive t han t he ot hers, and it is ext rem ely difficult t o t ell t hem apart j ust by looking at an im pressive resum e. I t herefore have learned t hat when it com es t o hiring a proj ect m anager, an em ployer cannot t ake a resum e t oo seriously. A com pany can only learn t he value of t he proj ect m anager once he or she has st art ed t he act ual proj ect , as t he t alent s lie in t he day t o day proj ect m anagem ent . But when select ing proj ect m anagers, an em ployer oft en does not have t hat kind of luxury. I n lieu of personal knowledge about a proj ect m anager's skills, prospect ive em ployers should focus on t he j ob candidat e's m ost recent proj ect responsibilit ies, t echniques, and m et hods. Oft en, asking t he candidat e t o respond t o a hypot het ical scene is a good way t o det erm ine t he candidat e's suit abilit y as a proj ect m anager ( e.g., request ing t hat a candidat e illust rat e t he m et hods and t echniques t hat he or she uses on a proj ect ) . Addit ionally, good candidat es would be able t o m arket t hem selves bet t er by describing t he value t hey would bring t o t he organizat ion. Som e of t he key fact ors in ident ifying a suit able proj ect m anager are

•

Ensuring t hat t he individual can sust ain t he role of proj ect m anager t hroughout t he proj ect life cycle

•

Gaining support from ot her depart m ent s or m anagers in select ing t he individual

•

Ensuring t hat t he individual has t he appropriat e skillset s and knowledge

I clearly recall a t roublesom e proj ect at a Fort une 50 client , who had appoint ed t he wrong proj ect m anager t o lead t he proj ect . The im m ediat e result s were rosy, but t hey result ed in a proj ect t hat was eight een m ont hs behind schedule, over budget by $250,000, had ineffect ive docum ent at ion, and had a baseline t hat gave a new m eaning t o t he word " flexible." The proj ect was an ut t er failure, and t he individual was m erely reassigned t o anot her depart m ent . Aft er reviewing t he proj ect result s, it was decided t hat success could have been achieved, had t he correct proj ect m anager been assigned t o t he helm ( see Figure 2.2 ) .

Figure 2 .2 : Skills needed by proj ect m anagers

ATTRI BUTES OF A PROJECT MAN AGER For about t hree years as a proj ect m anager, I failed t o list en t o m y t eam m em bers and cam e across as arrogant . The one t hing I learned from experience is t hat right act ion get s right result s and wrong act ion get s wrong result s. This kept dr iving m e com pulsively t o consider what at t ribut es I needed t o possess if I ever was going t o be an out st anding proj ect m anager. Proj ect m anagem ent , as a profession, has changed t hrough t he years and has produced m any good proj ect m anagers who have risen t o higher levels, consult ed world - wide, and oft en st art ed t heir own organizat ions due t o t heir broader underst anding of business principles. Wit hin t he proj ect m anagem ent profession, a m anager quickly becom es well- k now n in a very short period of t im e; client s ident ify t hose proj ect m anagers who are good and t hose who cannot perform well ( see Figure 2.3 ) . The following personal at t ribut es dem onst rat e t he profile of a good proj ect m anager: •

Self- confident

•

Problem solver

•

Good list ener

•

Able t o gain t he respect of t he t eam

•

An effect ive com m unicat or

•

Capable of react ing dynam ically and m aking decisions quickly

•

Considered a professional

•

A t eam player

•

Knowledgeable about proj ect m anagem ent

Figure 2 .3 : Underst anding t he need for good proj ect candidat es Proj ect m anagem ent consult ant s are norm ally dist inguishable from ot her com pany m anagers by t he following at t ribut es:

1. Reput at ion. The proj ect m anager is well- known by nam e in his

or her indust ry and is oft en called upon t o deliver papers, case st udies, and new concept s t o t his audience. 2. Experience. The proj ect m anager has sufficient experience and

has com plet ed m any proj ect s. 3. Leadership. The proj ect m anager possesses t he necessary

leadership skills t o lead people. 4. Present at ion skills. The proj ect m anager has t he abilit y t o

com m unicat e on all levels in order t o inform about proj ect st at us. 5. Expert ise. A proj ect m anager is norm ally em ployed because he

or she is an expert on t he subj ect and can speak wit h confidence on any pro j ect discipline. 6. Professionalism . The proj ect m anager, who belongs t o

reput able proj ect organizat ions, abides by a code of et hics specifically designed for t he proj ect profession, t hus ensuring t hat client s, organizat ions, and societ y are able t o ent rust proj ect m anagers wit h t heir daily dut ies. Know ledge of Proj ect Managem ent The first st ep for a newcom er t o becom e qualified in proj ect m anagem ent is t o com plet e a program of educat ion. Meet ing wit h ot hers who are learning about proj ect m anagem ent is helpful, but it t akes t im e. Alt ernat ively, a prospect ive proj ect m anager can gat her t he inform at ion on his or her own. Those new t o t he profession don't always need degree program s or pay large sum s of m oney j ust t o learn proj ect m anagem ent . Many of t he world's leading proj ect m anagers learned t heir skills and t echniques from experience and on- the- j ob t raining. That 's where t he best secret s lie, and t hat 's why I t hought sharing m y experiences wit h proj ect m anagem ent would be helpful. Technical Aut horit y Proj ect m anagers oft en t ell m e t hat , as proj ect m anagers, t hey do not need t o underst and t he t echnology or t echnical issues because t he t echnical resources working on t he proj ect will be responsible for t he t echnical det ail. Unfort unat ely, in t he I T environm ent t oday, it is im port ant for all proj ect m anagers t o be well- versed in t he relevant

proj ect t echnology ( including it s applicat ions and processes) and be able t o com m unicat e on t echnical issues wit h t he "t echies." The m aj orit y of organizat ions t hat em ploy proj ect m anagers insist t hat t he proj ect m anagers be able t o t ake t echnical decisions and t hat t hey possess t he necessary t echnical skill set s t o be on a sim ilar level as t he t echnical st aff. I have heard m any I T resources com plain bit t erly about proj ect m anagers who haven't got t he foggiest not ion of what needs t o be done t echnically. The result is oft en t hat m any of t hese resources sim ply carry on wit h t heir own developm ent process and view t he proj ect m anager only as an adm inist rat ive m anager who coordinat es t im e sheet s and ensures t he delivery of st at us report s. Proj ect m anagers who are not well versed on t he t echnical level find t hem selves ( 1) isolat ed, ( 2) lacking in credibilit y, ( 3) not consult ed t echnically on m aj or developm ent issues, ( 4) not t aken seriously, and ( 5) possibly even provided wit h false inform at ion. Proj ect m anagers who underst and t he t echnology and can use it pract ically can apply such knowledge wit h out st anding result s. Proj ect m anagers also need t o be cert ain t hat t hey have obt ained t he necessary proj ect aut horit y from t he proj ect sponsor and t hen com m unicat e t his t o all st akeholders. This senior execut ive involvem ent oft en does t he t rick! I always encourage proj ect m anagers t o m ake t echnical decisions if and when an opport unit y arises, or t o be involved in any way possible, by playing t he role of facilit at or or negot iat or wit h t he st aff. Sun Tsu said I f t he general's em ploym ent of his m ind is not in harm ony wit h t he arm y, even t hough t he form at ion's light ness and heaviness are correct , and t he front and rear are appropriat e, t hey will st ill not conquer t he enem y. Abilit y t o I dent ify and Resolve Problem s Problem s will arise on any proj ect , no m at t er how m uch planning and effort have been m ade t o avoid t hem . Recovering from any such problem m eans t hat t he earlier t he proj ect m anager can address t he problem s, t he bet t er. I dent ifying problem s m ay require t he proj ect m anager t o review t asks wit h resources in order t o find t he real causes of t hese problem s. I f t he causes are not wit hin t he m anager's own cont rol or aut horit y, t hen he or she m ust go t o t he proj ect sponsor and seek advice t here. As alarm ing as t his m ay seem , it m ay m ean st opping t he proj ect unt il a solut ion is found, which is a good suggest ion. Rem em ber, t he earlier you m ake the input t o correct t hings, t he sm aller t he input required.

Cont inuing t o let t asks and m ilest ones go off t rack will m ake it m ore difficult t o correct t he sit uat ion. Abilit y t o Take Decisions An im port ant at t ribut e of any proj ect m anager is t he abilit y t o t ake decisions on a proj ect . I n m eet ings, proj ect m anagers are oft en challenged t o m ake decisions t hat are crucial in m oving t he proj ect forward. I f t he proj ect m anager cannot effect ively m ake decisions, t he proj ect surely fail. Abilit y t o Select and M anage a Proj e ct Te a m I t is im port ant t hat t he proj ect m anager be able t o draw up a prelim inary list of people who will be needed on t he proj ect . He or she can be do t his by select ing t hose individuals who are available wit hin t he organizat ion and who possess t he relevant skills and experience required by t he proj ect . The proj ect m anager should be able t o guide and init iat e t he ext ernal hiring process for t hose t eam m em bers who are unavailable. Table 2.2 list s som e of t he key fact ors t hat should be kept in m ind when select ing t eam m em bers.

Ta ble 2 .2 : Team select ion checklist Select ion Crit eria

N ecessary

Candidat es have t he skills and expert ise for t he proj ect .

?/font>

Candidat es are available t o rem ain for t he full durat ion required on t he proj ect .

?/font>

Candidat es are t eam players.

?/font>

Candidat es are result s- orient at ed and can set goals.

?/font>

Candidat es are opt im ist ic about t he proj ect and out com e.

?/font>

Candidat es are t rust wort hy.

?/font>

Candidat es are able t o work on m ult iple t asks in isolat ion.

?/font>

Rem em ber, once t he proj ect m anager has select ed t he t eam m em bers, t he success of t he proj ect will depend on t he m anager's abilit y t o keep t he t eam focused, opt im ist ic, and com m it t ed t o achieving t he overall proj ect obj ect ives. However, it is not uncom m on for personal problem s t o

arise while working on a proj ect , and t he proj ect m anager should be able t o ident ify m any of t he sym pt om s ahead of t im e. The proj ect m anager should have t he experience and abilit y t o work wit h all people, irrespect ive of any individual's race, religion, nat ionalit y, age, or gender. The proj ect m anager and t he individual should im m ediat ely deal wit h any conflict t hat arises, and t he m anager should use t he m ost appropriat e course of act ion t o resolve t he problem . Addit ionally, t he abilit y t o praise and recognize t he proj ect t eam is im port ant . I t is essent ial t hat when t he t eam has worked hard t o m eet obj ect ives, oft en under difficult circum st ances, t hat t hey are awarded t he recognit ion. Having a Professional Approach Proj ect m anagers should want t o be considered as professionals. The st at us affect s t he qualit y of life for all people on t he proj ect , organizat ion, and even in societ y. Therefore, it becom es vit al t hat a proj ect m anager conduct s work in a professional m anner in order t o earn and m aint ain t he confidence of t eam m em bers, colleagues, em ployees, em ployers, client s, and t he public. The following is a code of et hics t hat proj ect m anagers should use t o help m aint ain t heir professionalism :

§

§

As proj ect m anager, I will st rive t o m aint ain high professional st andards in t he preparat ion and delivery of m y proj ect s, and I will be held account able for t he success or failure of t hose proj ect s. Regarding t he act ual work aspect of m y proj ect , I will st rive t o provide t he leadership, t rust , t ools, and support t o ensure all proj ect s are com plet ed on t im e, wit hin cost , specificat ion, and t o m y client s' requirem ent s.

Professionalism refers t o being able t o encourage respect and honest y in all business- relat ed m at t ers and during t he course of any proj ect . I t is im port ant t hat proj ect m anagers ensure t hat all client or em ployer inform at ion be kept confident ial and not lead t o a sit uat ion where t here is a conflict of int erest . Proj ect m anagers also have a dut y t o t heir respect ive com m unit ies, by ensuring t hat no proj ect be im plem ent ed in any locat ion where it could possibly place lives and propert y at risk. An appropriat e quot at ion from one of hist ory's fam ous proj ect m anagers can be used t o describe et hics. The general m ust be right eous. I f he is not right eous, t hen he will not be severe. I f he is not severe, t hen he will not be awesom e. I f he is not awesom e, t hen t he t roops will not die for him . Thus right eousness is t he head of t he arm y. —Sun Tzu

Proj ect M anagem ent Consult ant s Being hired as a proj ect m anagem ent consult ant present s a unique set of challenges. First , as a consult ant , t he proj ect m anager has been em ployed by a client because t hat m anager possesses or has dem onst rat ed t he necessary abilit y t o m anage proj ect s. Second, t his proj ect m anager also has t o adj ust t o t he client organizat ion and people, and t his can t ake t im e t o ram p up. The following are som e of t he issues t hat a proj ect m anager can expect t o find and adj ust t o at a client sit e. Challenges •

Adj ust ing t o t he prescribed client proj ect m et hodology or processes

•

Obt aining an underst anding of t he organizat ion and it s funct ional areas

•

Underst anding organ izat ional polit ics ( e.g., who cont rols t he proj ect )

Benefit s •

Having an obj ect ive plat form t o consult on proj ect processes, t echniques, and m et hods wit hout any career lim it ing m oves

•

Being able, as an independent consult ant , t o ask t he quest ions ot her perm anent st aff usually m ust avoid addressing

M a na ging Virt ua l Proj ect Tea m s For m any proj ect m anagers, m anaging a virt ual proj ect t eam is becom ing an ever- increasing realit y, as m ore and m ore organizat ions are int egrat ed and drawn t oget her on a global scale. Geographically dispersed t eam proj ect t eam are com m on in t he new global econom y. I recall being assigned t o m anage a proj ect in New Jersey, where I quickly found out t he locat ions of m y proj ect t eam : •

The cont ract or was locat ed in Georgia.

•

The execut ive sponsor was locat ed in California.

•

The business owners were locat ed in New Jersey.

•

The developers were respect ively locat ed in Germ any, I reland, and Singapore.

•

The analyst s worked m ost ly from t heir hom es in Virginia, New York, and Pennsylvania.

Today, proj ect t eam s est ablish com m unicat ion prim arily t hrough t he use of elect ronic m eet ing room s. Com m unicat ion t ools such as t elephonic conference bridges, e- m ail, calendars, docum ent sharing, and video conferencing are becom ing m ore com m on on proj ect m eet ings. The biggest challenges encount ered on virt ual proj ect s are t aking int ernat ional t im e zones int o account , underst anding one anot her, and est ablishing a plat form for effect ive com m unicat ions ( see Figure 2.4 ) .

Figure 2 .4 : Working wit h decent ralized t eam s and proj ect s The proj ect m anager relies on t he int egrit y of t he virt ual proj ect t eam t o receive and underst and t heir respect ive delegat ed proj ect t asks and perform t hem accordingly, wit hout t hese resources co m ing back and st at ing t hey did not underst and t he urgency and full nat ure of t he t ask. I n order t o help t he success of t he virt ual t eam , t he proj ect m anager needs t o est ablish cert ain crit eria.

•

The proj ect m anager should be cert ain t hat effect ive elect ronic com m unicat ion t ools are put in place. ( i.e., e- m ail, I nt ernet , Voicem ail, et c.) Any e- m ail syst em should be set up correct ly, in a st andardized m anner, in order for all m em bers t o receive and send m ail.

•

Mail should be writ t en in an effect ive m anner t hat com m unicat es t he precise inform at ion t o t he recipient s.

•

The proj ect m anager should develop and im plem ent a com m unicat ion plan t hat guides virt ual proj ect m em bers on all t he com m unicat ion form at s used on t he proj ect , frequency of m eetings, tim e zones, m ail, how t o deal wit h urgent t asks, and so fort h.

•

The proj ect m anager should set up a cent ralized proj ect inform at ion port al for all virt ual m em bers t o access t he relevant proj ect dat a and inform at ion.

•

He or she should creat e a schedule of pre- arranged telepho nic conference calls for proj ect st at us m eet ings.

•

He or she should arrange a face- t o- face m eet ing during proj ect init iat ion at a kick-off m eet ing or workshop, a face- to- face during proj ect execut ion, and anot her one aft er proj ect im plem ent at ion.

Proj ect M anager Responsibilit ies The role of t he proj ect m anager is so crit ical on a proj ect t hat it is im port ant t o ident ify t he m inim um basic responsibilit ies t hat are required from proj ect m anagers. Table 2.3 list s t hese responsibilit ies. Ta ble 2 .3 : I T proj ect m anager responsibilit ies Responsibilit ies

Checklist

Define and scope t he proj ect correct ly.

?/font>

I dent ify and select proj ect resources—team and m at erial resources.

?/font>

Lead t he proj ect t eam t hrough each phase of t he proj ect .

?/font>

Ta ble 2 .3 : I T proj ect m anager responsibilit ies Responsibilit ies

Checklist

Est im at e and creat e t he proj ect budget .

?/font>

I dent ify and m anage all issues and risks on t he pr oject .

?/font>

Creat e and m aint ain t he proj ect plan.

?/font>

Manage all changes t o t he proj ect .

?/font>

Ensure t hat all proj ect t asks and deliverables rem ain on t rack and wit hin cost .

?/font>

I dent ify organizat ional polit ics and play it well.

?/font>

Manage t he proj ect folder and relat ed docum ent at ion.

?/font>

Com m unicat e and m aint ain proj ect progress on m eet ings and st at us report s.

?/font>

LEADERSHI P ON THE PROJECT The m ain difference bet ween a leader and a m anager is t hat leaders have follow ers! Proj ect m anagers need t o ident ify what leadership pot ent ial t hey possess. The following sect ion present s som e of t he m ost frequent ly used t ypes of leadership st yle I have encount ered.

Charism at ic or Referent Pow er These proj ect m anagers, t hrough shear personalit y and t heir posit ion held wit hin t he com pany, have t he abilit y t o quickly m ot ivat e and influence proj ect t eam m em bers. Nat urally, t he force of t he m anager's personalit y com m ands t he at t ent ion of t he proj ect st aff: They t end t o list en and t o do t he m anager's bidding. Judicial or Form al Pow er Proj ect m anagers who fall int o t his cat egory are norm ally respect ed, confident , friendly, and have a sense of purpose t o see t he proj ect t hrough t o t he end. They are also em pat het ic t o t he proj ect st aff. Many proj ect m anagers fall wit hin t his cat egory.

Sit uat ional Pow er This st yle is oft en a com binat ion of leadership st yles and is dependent upon t he specific sit uat ion t hat dem ands it . Proj ect m anagers in t his cat egory m ay exhibit an aut ocrat ic st yle in one sit uat ion and a m ore j udicial st yle in t he next . For exam ple, on Monday, a subordinat e on a proj ect aut horizes proj ect changes from a vendor wit hout t he proj ect m anager's knowledge, result ing in t he proj ect m anager reprim anding t he m em ber for t he wrongful act ion. On Thursday, however, t his sam e proj ect m anager gives t he proj ect t eam a m ot ivat ional speech, com plim ent ing t hem for all t heir hard work. THE PROJECT MAN AGER OF TOMORROW Today's t rends indicat e t hat t he m aj orit y of em ploym ent agencies and em ployers are est ablishing t ough ent ry crit eria for any prospect ive proj ect m anagers. Client s have learned from past experiences t hat a proj ect m anager at t he helm of an im port ant proj ect does not necessarily im ply success. I nst ead, client s are set t ing higher st andards for fut ure proj ect incum bent s. Client s expect proj ect m anagers t o be able t o

§

Run proj ect s aut onom ously and m anage t hem selves

§

Accurat ely est im at e and t rack proj ect schedules and cost s

§

Com m unicat e quickly and efficient ly at all levels of business

§

Be creat ive and t hink out -o f- the- box

§

Underst and how businesses work, who runs t hem , and what it cost s t o run t hem

§ §

Be account able for a proj ect 's success Ride t he wave of change and be able t o int egrat e t he product s int o t he m arket

LESSON S LEARN ED FOR BECOM I NG AN I T PROJECT MAN AGER Wit hout learning from past m ist akes or experiences, a proj ect m anager will never be able t o succeed. Several lessons I have learned from include t he following:

§

I t is im port ant t o underst and t he t echnical aspect s of a proj ect and at t em pt t o m ake t echnical decisions; ot herwise, t he proj ect t eam will lose confidence in t he proj ect m anager's abilit y and m ay st art t o m ake t heir own decisions or even ask ot her m anagers for t heir opinions.

§

A proj ect m anager should never cont inue on a project where t here are t wo proj ect m anagers running t he sam e proj ect .

§

There m ust be a proj ect sponsor in place or t he proj ect will not have t he backing t o push it forward.

Phase Com plet ion Checklist The proj ect m anager should ensure t hat t he following cont ractual docum ent at ion and it em s are obt ained from and negot iat ed wit h t he client prior t o st art ing t he proj ect : •

Let t er of appoint m ent as proj ect m anager

•

Verificat ion of proj ect sponsor ident ificat ion and select ion

•

List of dut ies and responsibilit ies

•

Writ t en agreem ent of an incent ive program ( if bot h proj ect and organizat ional goals are m et )

•

All com plet ed adm inist rat ive form s, such as securit y clearances and access

Ch a pt e r 3 : Pr oj e ct Con ce p t s PROJECTS I N M OTI ON This chapt er explains t he core fundam ent als of what const it ut es a really good proj ect . I n addit ion, t his chapt er at t em pt s t o explain why proj ect s seem t o fail. Do proj ect s fail because of poor est im at ion or because of poor im plem ent at ion by t he proj ect t eam ? Once proj ect m anagers underst and t he basic issues involved in proj ect m anagem ent , t hey will m ore fully appreciat e t his chapt er, which deals wit h proj ect init iat ion. Let m e begin t his chapt er by st at ing t hat proj ect s underst andably ( 1) are t em porary by nat ure ( in t hat t hey have a beginning and an end) , ( 2) are very unique, ( 3) have goals t hat need t o be m et , ( 4) have m ult iple act ivit ies t hat need t o be coordinat ed, som et im es across funct ional depart m ent s, and ( 5) have high im pact s t o a business. Globally, com panies invest billions of dollars annually on I T solut ions. I n addit ion, m any organizat ions offer visionary solut ions t hat all call for knowledgeable proj ect m anagers t o plan, execut e, cont rol, and end proj ect s ahead of any com pet it ion. Sadly, m any of t hese proj ect s com e in behind schedule and over budget , and fail. Part of t his book focuses on t hose proj ect s in t urm oil and offers ways t o get t he great er m aj orit y of t hese proj ect s back on schedule, bot h wit hin budget and wit hin specificat ion. Many proj ect s are canceled before t hey are ever com plet ed and m any exceed t heir original est im at es. The financial cost s of t hese failures and overruns are j ust t he t ip of t he iceberg. This chapt er ident ifies causes of and offers ways t o resolve m any of t hese issues. On t he success side, roughly 16.2 percent of proj ect s are com plet ed on t im e and on budget . I n t he larger organizat ions, t he news is even worse: Approxim at ely 9 percent of t heir proj ect s com e in on t im e and on budget . And, even when t hese proj ect s are com plet ed, t hey are no m ore t han a m ere shadow of t he original funct ional requirem ent s.[ 1 ] Today, when proj ect m anagers t ake on a proj ect , t hey m ust face t he realit y t hat m any client s are increasingly aware of how proj ect s m ust align wit h business processes and st rat egy. As a result , t hese client s expect proj ect m anagers t o be able t o t ranslat e t heir requirem ent s int o effect ive im plem ent at ions. Table 3.1 port rays t he t ransit ion t hat proj ect m anagers are expect ed t o m ake happen.

Ta ble 3 .1 : Transit ion of client expect at ions in proj ect m anagem ent Fr om

To

I nform at ion Age

Knowledge Age

Long cycle t im es

Short cycle t im es

Nat ional

Global

I ndividual proj ect t eam

Team - based

Lip service

Custom er relationships

Cost focus

Cost and growt h Focus

Minim al change

Rapid change

Minim al int egrat ion

Tot al business int egrat ion

Qualit y

CMM Levels 4 –5

Proj ect - based

Solut ion- based

[1 ]

I nform at ion used wit h perm ission of t he St andish Group I nt ernat ional, CHAOS Research Report , 1995 PROJECT METHODOLOGI ES The Syst em Developm ent Life Cycle ( SDLC) Concept Many organizat ions have t heir own unique proj ect m et hodologies concent rat ing on soft ware developm ent and delivery. The SDLC is basically a form al set of act ivit ies and phases used t o guide t hose involved in t he proj ect t hrough t he com plet e developm ent of an I T solut ion. Bot h adopt ing and consist ent ly im plem ent ing a com m on SDLC across an organizat ion are vit al elem ent s in providing proj ect m anagers wit h t he abilit y t o deliver qualit y solut ions for client s. One of t he m ost popular m et hodologies being used t oday is t he Wat erfall m et hodology. I t is st ep- by- st ep, linear m et hodology t hat guides a proj ect m anager t o com plet e one phase of t he proj ect before m oving ont o t he next . Anot her popular m et hodology is t he Tim eboxing m et hodology. I t 's used in sit uat ions where short , rapid developm ent and delivery are needed ( i.e., prot ot yping) , t hus allowing each phase of t he m et hodology t o be repeat ed unt il t he desired funct ionalit y of t he product is obt ained. Each m et hodology has it s own unique set of advant ages and disadvant ages, as shown in Table 3.2 .

Ta ble 3 .2 : Com parison of w at erfall and t im eboxing proj ect m et hodologies W at erfall

Tim eboxing

Advant ages

Advant ages

Most com m only used Sequential st ep- by- st ep process Client involved early in process

Focuses t eam on im m ediat e result s Rapid delivery May lead t o good product ivit y Client able t o see result s up front

Disadvant ages

Disadvant ages

Not all requirem ent s are defined up front

Requires planning fo r final release

Client usually sees result s downst ream

More com plex t han Wat erfall process Need t o focus on t he crit ical pat h

When developing any I T syst em it is im perat ive t o use a phased approach in developing eit her a product or solut ion for t he client . I f a proj ect m anager sim ply went about blindly developing a soft ware product or solut ion wit hout a physical or logical st ruct ure, it is m ore t han likely t hat he or she would experience t rem endous frust rat ion during t he developm ent process. The m ost likely problem s encount ered would occur in t he areas of ( 1) com m unicat ion, ( 2) scheduling, ( 3) int egrat ion, and a ( 4) delay on delivery t arget s. Prim arily t hen, t he process of syst em developm ent is oft en m odeled as a series of different phases ( 1 - n) t hat define t he proj ect life cycle. Som e act ivit ies sim ply cannot happen, or it would be less product ive for t hem t o happen, unt il t he preceding one has been accom plished. For exam ple, "Approving t he Technical Design Specificat ion" needs t o follow "Developing t he Technical Design Specificat ion," while "Creat ing t he I m plem ent at ion Plan" nat urally follows an "Approved Proj ect Plan." Having said t his, t he proj ect m anager will need t o det erm ine whet her t he proj ect , or t he circum st ances facing it , dem ands variat ions in som e of t he sequencing, or parallel running of ot hers. Table 3.3 port rays t he generic, defined proj ect phases t hat can be used on a proj ect .

Ta ble 3 .3 : Various proj ect m et hodo logy approaches Approach # 1

Approach # 2

Concept or ident ificat ion

Requirem ent s definit ion

Analysis and design

Requirem ent s analysis

Const ruct ion, building, or execut ion

Prelim inary design

Testing

Det ailed design

Qualit y syst em assurance

I m plem ent at ion

I m plem ent at ion or delivery

Syst em t est ing

Maint enance or support

Accept ance t est ing Maint enance and operat ion

Underst anding t he Proj ect Life Cycle Very oft en, t eam m em bers will only be used on cert ain phases of t he SDLC, whereas st aff m em bers who look at t he qualit y assurance or configurat ion m anagem ent of t he proj ect will be involved t hroughout t he proj ect . Therefore, we see clearly t hat a proj ect cannot be com plet ed in isolat ion or as an individual effort . Team dynam ics are a crucial considerat ion when select ing each t eam m em ber, and each cont ribut es his or her t alent s t o t he overall success of t he proj ect . Most organizat ions can m axim ize im provem ent s in t heir proj ect perform ance by sim ply doing t he basics right . I t is not usually necessary t o im plem ent a sophist icat ed proj ect m et hodology. I n fact , if a proj ect m anager is being advised or is considering im plem ent ing som e form of m et hodology t hat he or she does not fully underst and, t ypically one of t wo t hings happen: Eit her t he proposed approach is t oo com plex, or t he organizat ion is not cult urally ready t o im plem ent it . Life Cycle Phases A successful proj ect m anagem ent process relies on t wo act ivit ies: proper planning first , and t hen proj ect execut ion. These t wo sequent ial act ivit ies form t he basis of every proj ect life cycle and can be expanded t o suit t he cont rol requirem ent s of every t ype of proj ect in every area of proj ect m anagem ent applicat ion. The proj ect life cycle, charact erized by a series of "m ilest ones," det erm ines when t he proj ect st a rt s, t he "cont rol gat es" t hrough which it m ust pass, and when t he proj ect is finished. The phased life cycle approach gives businesses m ore t im e t o underst and and assess fut ure requirem ent s and t o m ake changes during t he act ual im plem entation phase. I n add it ion, a phased approach gives t he client quick wins, even at t he very first phase.

The life cycle phases are im port ant reference point s for t he proj ect m anager. They ident ify t he syst em developm ent life cycle in sequent ial t im e periods t hat som et im es overlap one anot her. However, t he activities charact erist ic of one phase m ay be perform ed in ot her phases. For exam ple, alt hough m ost of t he st aff effort in analyzing requirem ent s occurs during t he requirem ent s analysis phase, som e of t hat act ivit y cont inues at lower levels in lat er phases. Discovery Pha se I n t he discovery phase, t he proj ect t eam , which usually includes t he proj ect m anager and select ed business st akeholders ( i.e., execut ives, st rat egist s, analyst s) , explores a client 's fut ure and assist s in developing t he vision and st rat egy t he client should t ake. The t eam also t ransform s t hese act ions int o a workable solut ion blueprint t hat is unique for t he business and I T needs of t he client . Addit ionally, t he discovery phase is an im port ant st ep because it allows t he t eam t o t ake a snapshot of t he client 's current organizat ion and it s processes. This allows t he proj ect t eam t o ident ify and recom m end im provem ent s ( bot h applicat ions and enabling t echnologies) needed t o realize t he client 's vision. Concept Phase I n t he concept phase, a requirem ent definit ion t eam ident ifies and develops t he funct ional, t echnical, dat a, capacit y, archit ect ure, perform ance, and t raining requirem ent s t oget her wit h t he client . The t eam pinpoint s any cust om funct ionalit y t hat m ay be necessary and docum ent s t his form ally. The conclusion of t his phase is m arked by a proj ect review, at which t im e t he solut ion is present ed and evaluat ed. Design Phase The baseline funct ional specificat ions form a cont ract bet ween t he requirem ent definit ion t eam and t he soft ware developm ent t eam . They also provide t he st art ing point for prelim inary design. Execut ion Phase I n t his phase t he developm ent t eam fully designs t he solut ion, eit her as separat e applicat ions, m odules, or needed int erfaces. Resources are allocat ed t o assist t he developm ent t eam , and t he t eam works against set t im elines. Higher- level execut ives usually hold a set of reviews, which provides an opport unit y t o evaluat e t he design present ed by t he developm ent t eam . QA Phase The qualit y assurance t eam perform s ext ensive t est ing and validat ion on t he solut ion developed by t he build t eam . Test s are carried out in

accordance t o t he design crit eria, and reviews lead t o successful release of t he solut ion, allowing t he solut ion t o be im plem ent ed. I m plem ent at ion Phase Aft er t he client has accept ed t he solut ion, t he next st ep is t o consider t he im plem ent at ion at t he client organizat ion. The im plem ent at ion of t he solut ion carries num erous responsibilit ies and act ivit ies, such as t raining of resources, client knowledge t ransfer, and docum ent at ion, all of which need t o be scheduled and coordinat ed. Closure Phase At t he closure phase t he several priorit ies need t o be suit ably addressed: All resources should be reassigned back t o t he organizat ion, post- proj ect reviews need t o be held wit h t he client , and sufficient post - proj ect m aint enance and support should be in place for t he success of t he solut ion. The success of a proj ect depends on choosing a good proj ect m anagem ent m et hodology at t he beginning ( see Figure 3.1 ) . Three elem ent s help ensure a proj ect 's success: •

Managing t he proj ect t hrough it s life cycle

•

Monit oring and cont rolling t he schedule, budget , qualit y, and risk

•

I nt egrat ing m et hods and t ools, which builds a foundat ion for cont inuous im provem ent s in product ivit y, t eam work, and com m unicat ion beyond t he init ial im plem ent at ion

Figure 3 .1 : Managing t he proj ect t hrough it s life cycle Figure 3.2 shows an exam ple of a life cycle m et hodology.

Figure 3 .2 : An exam ple of a t ypical e- com m erce proj ect m et hodology

FACTORS AFFECTI N G PROJECTS The t hree m aj or fact ors indicat ing a proj ect will succeed are ( 1) t im ely user involvem ent , ( 2) execut ive m anagem ent support , and ( 3) a clear user requirem ent st at em ent . There are ot her success crit eria, but wit h t hese t hree elem ent s in place, t he chances of success are m uch great er. Wit hout t hem , organizat ions run a high risk of failure. Organizat ions should carefully consider whet her proj ect s are t oo excessive t o undert ake in one go, as t his approach m ay im pact t he success or failure of a proj ect . This is part icularly im port ant if a proj ect is influenced by m any business dependencies. The num ber of proj ect failures could be dram at ically reduced by dividing t he ent ire proj ect int o relat ively sm aller proj ect s or phases, wit h each successive one being reviewed and approved before t he next one is st art ed. The advant age of such a st ruct ured approach is t hat it helps t o reduce t he com plexit y of planning, m onit oring, and cont rol. Table 3.4 port rays negat ive fact ors and solut ions t hat have been used t o overcom e t hem , t hus aiding t he successful delivery of proj ect s. Ta ble 3 .4 : Fact ors affect ing proj ect m anagem ent Fact ors effect ing I T Proj ect s

Recom m ended Solutions

I ncom plet e requirem ent s Lack of user involvem ent Lack of resources

Obt ain all requirem ent s

Unrealistic expect at ions Lack of execut ive support

Negot iat e wit h t he client

Changing requirem ent s & specificat ions Lack of planning

Adopt change cont rol

Client no longer needs proj ect Lack of I T m anagem ent 10. Technological illit eracy

I nvolve all st akeholders Develop resource planning

Com m unicat e wit h and involve execut ives

I ncrease planning int o t he proj ect Det erm ine requirem ent s Hire correct resources Train st aff

The m ost significant cause of failure t o deliver t he business benefit s is inadequat e st aff preparat ion and t raining. There are several m aj or quest ions t hat proj ect m anagers should ask when m anaging and m onit oring a proj ect .

§

I s t he proj ect 's planning t im e scale adequat e for negot iat ion, purchase, developm ent , inst allat ion, t raining, and support ?

§

I s t his st ill a solut ion t hat is based on a st andard package im plem ent at ion?

§

Are t he changes t o working pract ices and financial procedures st ill m inim al and cont rollable?

§

Are t he cont ract and supplier relat ionships aligned t o t he proj ect ? Does t he vendor cont inue t o dem onst rat e a good underst anding of t he business requirem ent s?

§

§

Are t he m echanism s in place t o m anage request s for changes while t he proj ect is in progress and t o ident ify requirem ent s for t he next upgrade t o t he syst em ?

The use of appropriat ely skilled st aff and experienced suppliers is im port ant , and t he proj ect m anager needs t o be sure t hat he or she has obt ained t he best resources and m ade t he best est im at es. I f t he proj ect m anager select s incorrect resources, a significant increase in risk, including st opping t he proj ect , now exist s. I N TEGRATI ON CON SI DERATI ON S Do not underest im at e t he t im e and effort needed t o int egrat e a new syst em int o t he exist ing business and int erface it t o exist ing syst em s. Proj ect m anagers need t o be sure t hat t he plan allows som e cont ingency for slippage and t hat t hey are inform ed whenever st aff encount ers t his. Proj ect m anagers m ust plan for any int egrat ion t asks from t he st art of t he overall proj ect , not leave t hem unt il t he end. The following are som e considerat ions:

§

Review t hose int erfaces used on ot her proj ect s t hat m ay influence t his proj ect .

§

Define all proj ect int erface requirem ent s.

§

Be cert ain t hat t here are not t oo m any t hird- part y cont ract ors all working on separat e int egrat ion plans. A single, coordinat ed effort is m ore desirable.

§

I dent ify all possible risks and issues in a risk m anagem ent plan.

§

Define t he com m unicat ion bet ween all int erest ed part ies.

§

Define t he out put for each proj ect deliverables.

§

Docum ent t he dat a conversion process.

§

Est ablish a change cont rol procedure.

§

Be cert ain t hat t here is a plan for int egrat ion t est ing.

§

Ensure t hat a cont ingency plan t akes effect in t he event of syst em failure.

M AN AGI N G PROJECT RI SK Conduct ing a proj ect review during a proj ect provides an opport unit y t o revisit the issues and risks t hat t he proj ect is facing. Managem ent and t he I T proj ect t eam m ust m anage risk t hroughout t he ent ire proj ect life cycle. Using st rat egies t o reduce risk increases t he likelihood of a successful im plem ent at ion. I nt erviews wit h m anagem ent proj ect st aff and key users should cont ribut e t o a frank and open discussion wit h a cross sect ion of t he organizat ion's st aff about t he issues and risks. A key out com e of t he discussions is an assessm ent of t he overall risk t hat t he organizat ion needs to m anage. Bringing issues forward can also help t he proj ect t eam highlight needed act ions while t here is t im e for proact ive adj ust m ent s. I nform at ion t echnology proj ect failures m ake t he headlines every day. Wit h growing financial pressures and t he need for successful deploym ent of inform at ion t echnology, m anagem ent is increasingly focusing on t he result s of t heir invest m ent s. The proj ect review can be an effect ive m echanism for senior m anagem ent t o ensure t heir proj ect s are "under cont rol" and are st ill able t o deliver result s. I dent ifying Sources of Risk I nt ernal and ext ernal risks such as poor est im at es, design errors, and poorly defined roles on t he proj ect need t o be ident ified by t he proj ect m anager and t he proj ect t eam . Figure 3.3 shows t he basic process of how t o ident ify and m anage risks.

Figure 3 .3 : Underst anding proj ect risk m anagem ent I dent ifying Pot ent ial Risk Event s These are event s t hat m ay occur during t he course of t he proj ect , such as a nat ural disast er or a vit al m em ber of t he t eam resigning. Developing a risk m anagem ent plan begins wit h a risk assessm ent t o det erm ine what risks exist , t he pot ent ial sources of risks, t heir probabilit y of occurring, and t he im pact on t he proj ect . Risk assessm ent is used t o develop t he risk avoidance plan, which det erm ines t he act ions t hat will be t aken t o avoid risks, and t he risk cont ingency plan, which det erm ines t he alt ernat ive act ions t hat will be t aken if t he risk im pact s occur. Risk assessm ent also defines an owner for each risk. Risk Analysis Risk analysis consist s of not hing m ore t han evaluat ing possible risks for t he probabilit y of t hem occurring, describing t he pot ent ial im pact , and est im at ing t he severit y of t hat im pact . For each risk, t he proj ect m anager

should assign a probabilit y ranking of avoidable, m anageable, unavoidable, or unknown , along wit h t he ident ificat ion of t he first possible im pact dat e. The risk analysis should describe t he risk im pact , or what will happen if t he event does occur. Bot h t angible result s ( e.g., financial im pact s) and int angible losses ( e.g., reduced client sat isfact ion or t eam m orale) should be considered in t he descript ion of t he im pact . This inform at ion m ay t hen be used t o define im pact severit y.

§

A rat ing of low severit y m eans "workarounds" are available.

§

A rat ing of m edium severit y indicat es no workarounds are available; however, t he risk it em does not im pact m ilest ones or proj ect t arget s.

§

A rat ing of high severit y indicat es t hat risks t hat do not have workarounds and will im pact t he proj ect m ilest ones, t arget , or success.

The risks should be priorit ized, for furt her analysis and developm ent , based on t heir probabilit y, im pact dat e, and severit y. Table 3.5 shows t he various risk avoidance t echniques t hat can be used on a proj ect . Ta ble 3 .5 : Risk avoidance t echniques and m et hods Risk Avoidance Techniques

Met hod

Creat ing "worst case scenarios"

Hold proj ect review wit h t eam

I nt erviews

Hold individual m eetings

Risk quest ionnaire

Develop and dist ribut e risk questionnaire

Decision t ree analysis

Use soft ware t ool or perform m anual analysis

Risk log

Creat e and it em ize all known risks

Risk I dent ificat ion For t he proj ect m anager, risks can com e from m any sources, but t hey can usually be cat egorized int o several areas.

1 . Technical risks. These risks t o t he proj ect are t echnical in nat ure and are t he result of com plexit y, int egrat ion issues, or t echnology. For t his class of risk, proj ect m anagers need t o be cert ain t hat t hey have t he required skills t o deal wit h or m it igat e any pot ent ial problem s t hat m ay arise. 2 . Financial risks. These risks include t hreat s t o t he proj ect budget —t he danger of unforeseen event s causing cost s overruns. 3 . Schedule risks. Schedule risks are fact ors t hat could cause delays in t he proj ect , pot ent ially delaying t he planned finish dat e. Oft en t here is a relat ionship bet ween financial and schedule risks in t hat delays oft en incur financial penalt ies and risks of delay can usually be rem oved—but at a financial cost . 4 . I nt ernal risks. Som et im es called proj ect risks, t hese risks em anat e from wit hin t he proj ect it self. They include fact ors such as t echnical failures, delays in carrying out scheduled work, errors by proj ect st aff, and so on. Generally speaking, t hese are risks t hat t he proj ect m anager can cont rol and is in a posit ion t o do som et hing about . 5 . External risks. Ext ernal risks, on t he ot her hand, are t hreat s t o t he proj ect t hat com e from t he ext ernal environm ent . They are som et im es referred t o as business risks and are out side t he cont rol of t he proj ect m anager. Exam ples in clude legislat ive changes ( which could render t he proj ect 's product s obsolet e) or changing m arket condit ions ( which could render t he business case invalid) . Risk Report ing Risks should be report ed const ant ly t hroughout t he proj ect , and a process should be est ablished whereby all risks are report ed t o t he necessary levels wit hin t he client or com pany. Periodic risk m eet ings should also be set up wit h t he proj ect t eam and client as early in t he proj ect as possible. The t op priorit y risks should be report ed in t he weekly st at us report s along wit h t he current st at us of com plet ion. Risk Mit igat ion Mit igat ion is t he process of creat ing st rat egies t o m inim ize t he im pact of t he risks on a proj ect . Mit igat ion st rat egies should det erm ine t he highest risk and it s associat ed priorit ies first . I t is possible t hat , for lower t ypes of risks, t he st rat egy would be t o t ake no act ion and prepare cont ingency plans in t he event t hat t hey should ever occur. The processes for developing m it igat ion st rat egies are as follows:

§

Define t he approach or st eps t o t ake.

§

I dent ify cont ingency plans for a worst case scenario.

§

Assign responsible part ies.

§

Define t he closure dat e and necessary crit eria.

PROCUREMEN T ON THE PROJECT Responsibilit y for Procurem ent on t he Proj ect The proj ect m anager is responsible for ensuring t hat t he necessary st eps have been t aken t o procure it em s for t he proj ect phases, and t hat t his process has t aken int o account t he various lead t im es for delivery t o t he im plem ent at ion sit e. Under norm al circum st ances t he proj ect m anager has a procurem ent m anager or assist ant working wit hin a corporat ion or com pany who does t he ordering and adm inist ers t he purchase ordering and receipt of proj ect goods. However, t he proj ect m anager should be sure t hat t he assist ant underst ands t he procurem ent process and t hat he or she is aware of delays caused by adm inist rat ion, paym ent s t o suppliers, and invoicing det ails. The proj ect m anager should be aware of any legal im plicat ions when placing cont ract s and purchasing equipm ent or services from suppliers and cont ract ors. Procuring Product s and Services for a Proj ect The proj ect m anager should ident ify from t he proj ect Work Breakdown St ruct ure ( WBS) which t asks require ( 1) hardware, ( 2) soft ware, or ( 3) t hose services or m at erials relat ed t o t he proj ect . Accordingly, once ident ified, t he proj ect m anager docum ent s t hese required I T it em s int o a st andardized specificat ion. This specificat ion is accordingly dist ribut ed t o m ore t han one supplier for quot at ion. Once t he proj ect m anager has received all t he necessary quot at ions, t he process of evaluat ing and select ing t he best product s or services and of select ing a preferred supplier begins. The best price is not always t he m ost im port ant fact or for supplier select ion, and proj ect m anagers should assess t hird part y suppliers by m eans of developing a crit eria suit ed t o t he I T solut ion. Table 3.6 displays a m inim um set of vendor select ion crit eria t hat is used t o det erm ine which vendor is best qualified t o m eet t he proj ect obj ect ives.

Ta ble 3 .6 : Vendor select ion crit eria Select ion Criteria

Supplier A

Supplier B

Supplier C

Supplier D

Supplier E

Experience

？ ？ ？ ？ ？ ？ ？ ？

？ ？ ？ ？ ？ ？ ？ ？

？ ？ ？ ？ ？ ？ ？ ？

？ ？ ？ ？ ？ ？ ？ ？

？ ？ ？ ？ ？ ？ ？ ？

Cost

$125,000

$100,000 $80,000

$167,500 $94,000

Com patible t echnology

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Certified st aff

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Proj ect m anagem en t

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Support ( 24??65)

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

References ( ?3)

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Geographic locat ion

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Providing of ?/fo nt> docum ent at i on

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

?/fo nt>

Training

TH E PROJECT OFFI CE ROLE The proj ect office is oft en referred t o as a "cent er of excellence" or "proj ect support office." I n basic t erm s, as organizat ions grow t heir proj ect port folios, t hey need t o cent ralize all proj ect inform at ion in order t o reflect t he best int erest s of t he com pany. The proj ect office should consist of bot h proj ect m anagers and proj ect adm inist rat ion st aff. Proj ect offices exist at different levels wit hin a com pany, and it is not uncom m on t o find m ore t han one proj ect office wit hin t he larger organizat ion or in different funct ional depart m ent s. An exam ple of t his is an I T proj ect office t hat looks aft er t he I T invest m ent s and proj ect s wit hin a large com pany, and, wit hin t hat sam e com pany, an execut ive- level proj ect office t hat reviews all proj ect s t hroughout t he com pany. I don't t hink it 's a necessit y t o have proj ect m anagers running a proj ect office, but t hey definit ely should have input int o it s developm ent and

should be account able for t heir proj ect s. A proj ect m anager brings a wealt h of valuable inform at ion regarding st andard proj ect m anagem ent pract ices as defined by t he Proj ect Managem ent I nst it ut e ( PMI ) , as well inform at ion about as t he developm ent , direct ion, and adherence t o a part icular organizat ion's m et hodologies. That is not t o say t hat adm in st aff cannot perform t he role of running t he proj ect office, but t hey should be skilled in all facet s of proj ect m anagem ent t o ensure it s success, and t hey should adhere t o t he guidelines set fort h by t he com pany's proj ect m anagem ent professionals. Roles and Responsibilit ies of t he Proj ect Office A proj ect office should report on any proj ect - relat ed inform at ion t hat is crucial t o t he success of delivering solut ions and proj ect s wit hin schedule and budget and should not place t he com pany at risk. The needs of specific proj ect office roles differ am ong organizat ions, but t hey all share som e com m on dist inguishing responsibilit ies ( see Figure 3.4 ) . Proj ect m anagers should rem em ber t hat it is up t o t he com pany t o det erm ine t he t ype of dat a it needs in order t o deliver valuable inform at ion. Typical exam ples of what a proj ect office is responsible for are §

The com m unicat ion of proj ect st at us

§

Cat egorizat ion of proj ect s ( by m anager, st at us, priorit y, depart m ent , region, et c.)

§

Resource allocat ion ( by proj ect and across m ult iple proj ect s)

§

I ssues t racking and resolut ion

§

Defect t racking and resolut ion

§

Docum ent reposit ory for proj ect - relat ed docum ent s ( i.e., scope docs, t echnical requirem ent s, proj ect chart er, agendas, m eet ing m inut es, cont ract s, proj ect m at rix, change m anagem ent decisions, et c.)

§

Tim e t racking of t asks

§

I nt egrat ed cost and schedule st at us

Figure 3 .4 : The proj ect office dependency Many proj ect offices should develop or use an applicat ion t hat allows organizat ions t o updat e and report on t he lat est proj ect inform at ion. Because t his inform at ion is cont ained in a dat abase, t he inform at ion can be report ed using a com m on report ing package or by export ing t o a com m on form at t hat could t hen be pulled int o a spreadsheet for addit ional analysis. An effect ive proj ect office will recognize t he need for different levels wit hin t he com pany t o be support ed by such a syst em . For exam ple, for all proj ect s wit hin t he com pany, execut ive m anagem ent m ay want t o see rolled- up inform at ion t hat has t he abilit y t o reveal m ore det ails if they need m ore specific inform at ion. Proj ect m anagers m ay need access t o t he ent ire proj ect inform at ion on proj ect s for which t hey are responsible. And t eam m em bers m ay only need access t o cert ain inform at ion relat ing t o t heir involvem ent in each proj ect . Using login securit y and perm issions in a flexible environm ent t hat is easily configurable for each individual workgroup can support t his requirem ent . My best advice t o proj ect m anagers would be t o exam ine t he needs of t he com pany and det erm ine t he requirem ent s of a proj ect office t hat will support business processes, goals, and vision. Then, research available solut ions t o support t hese requirem ent s or det erm ine if it is feasible t o

build a cust om ized syst em in - house. Obt ain recom m endat ions form ot her organizat ions ( bot h in and out of t he indust ry) , or even t ake a t est drive of t he com m ercial applicat ions available. Som e areas a proj ect office should be responsible for include

§

Business case developm ent

§

Proj ect plans ( developm ent and m aint enance)

§

Facilit at ion of st at us m eet ings

§

Risk m anagem ent

§

I ssue m anagem ent

§

Com m unicat ion planning

§

Docum ent at ion st andards

§

Budget m onitoring

§

Upper m anagem ent report ing

TYPES OF PROJECTS Most I T proj ect s are cat egorized int o t he following areas: ( 1) infrast ruct ure, which includes new or im proved t echnologies or processes, ( 2) m aint enance and upgrades t o exist ing syst em s, ( 3) new product developm ent and t he int roduct ion of new dist ribut ion channels, and ( 4) research and developm ent . The m aj orit y of proj ect s are chosen because t here is a dem and for a new product or because business require enhancem ent s t o out dat ed syst em s. This being t he case, proj ect m anagers will likely encount er t hree sizes of proj ect s: super, m edium , and sm all ( see Figure 3.5 ) .

Figure 3 .5 : Classificat ion of I T proj ect s Type 1 : Super Proj ect s These proj ect s are cat egorized as ext rem ely large and com plex; t hey oft en are t he result of st rat egic decisions based on t he com pany's st rat egy, archit ect ure, and planning. Business exam ples of t hese proj ect s include a m erger of t wo organizat ions, rat ionalizat ion of business processes, or t he developm ent of a new port folio of product s. I n pract ical t erm s we can refer t o t he following exam ples of super proj ect s: ( 1) t he Hum an Genom e proj ect , and ( 2) t he Mars Explorer proj ect . These proj ect s oft en exceed eight m ont hs in durat ion. Super proj ect s consum e vast am ount s of resources and com m it m ent from st akeholders, and resources are assigned on a full- t im e basis. Norm ally, special cont rols and st ruct ures are est ablished for t hese super proj ect s. I t is very com m on for subproj ect s t o form from a super proj ect , t hus raising t he issue of program m anagem ent . For t hese super proj ect s, where a m ore rigid st ruct ure is desirable, organizat ion chart s are useful for clarifying roles. Each t eam m em ber

knows his or her role on t he proj ect , including t he ext ent of his or her aut horit y and responsibilit y. Early W arning Signs The following early warning signs m ay indicat e t hat a super proj ect is going off t rack. 1. The corporat ion is wavering in it s com m it m ent t o t he

achievem ent of benefit s. This m ay be signaled by I S advisors assum ing responsibilit y for t he proj ect . 2. Key proj ect st aff m em bers have m oved on. 3. The supplier m akes frequent request s for variat ions,

clarificat ion, or addit ional funds. 4. The supplier needs redefinit ion of t he deliverables t o be

supplied. 5. There is a need t o involve ot her part ies not previously part of

t he proj ect or requirem ent s definit ion. 6. There is a lack of clarit y in, or frequent changes t o, t he

organizat ion of t he supplier. 7. There is slippage against agreed t arget dat es for delivery of

any part of t he solut ion. 8. There is frequent slippage of delivery dat es. 9. Proj ect m anager get s assurances t hat "all is well" wit hout

support ing evidence. Type 2 : Medium Proj ect s These proj ect s are cat egorized as being m edium in size, are ident ifiable, and have t o be archit ect urally aligned wit h t he com pany st rat egy and planning. The reasoning is t hat t hese proj ect s are dependent on ot her com put er syst em s and services. Proj ect s falling wit hin t his cat egory follow t he st andard proj ect m et hodology. These proj ect s cat er t o t he following business needs: ( 1) I nfrast ruct ure, ( 2) Port folio, and ( 3) Service Delivery. The im plem ent at ion t im e of m edium size proj ect s oft en exceeds five m ont hs and is t ypically high profile. All t he form al business analysis and proj ect docum ent at ion is required t hroughout each proj ect phase.

Type 3 : Sm all Proj ect s These are sm all yet im port ant proj ect s t hat need t o be m anaged t o com plet ion. They are oft en encount ered int ernally wit hin a depart m ent or business unit . Wit hout a proj ect m anager, t hese proj ect s will surely fail, and t he business operat ion will feel t he effect s. These proj ect s oft en t ake one m ont h or less t o com plet e, and t hey do not need t he form al approaches and proj ect docum ent at ion t hat ot her proj ect s do. Typically, t hese proj ect s would not need a business case, st rat egic alignm ent , Request for Proposal ( RFP) , or any cont ract ual docum ent at ion; however, the proj ect m anager is responsible for ensuring t hat t he proj ect is m anaged according t o t he st andard com pany deliverable process, in order not t o lose focus. Pract ical exam ples of such sm all proj ect s are ( 1) a server m igrat ion ( 2) or m inor changes t o a crit ical business applicat ion. For sm aller, m ore fluid proj ect s, where it is bet t er for each t eam m em ber t o work across as m any roles as possible, a proj ect m anager m ay want t o assure each individual t hat he or she is em powered t o fill what ever roles are necessary t o keep t he proj ect m oving. A sim ple proj ect is one where t he risk t o t he business is low: The following list present s som e guidelines t o ident ify t hese proj ect s. The solut ion is based on a st andard im plem ent at ion ( usually an offthe- shelf package) . The syst em does not cross business funct ions ( e.g., sales and product ion) and does not involve a m aj or redesign of business processes. There are no m aj or changes required. The num ber of cont ract ors t o m anage is only one or t wo. There will be no replacem ent of t he hardware t ype or operat ing syst em . There are no dependencies caused by links t o ot her proj ect s in an I S invest m ent program . The organizat ion has t he experience and capabilit y t o handle t his t ype of proj ect ( i.e., it has been done before, by t his t eam , in this business) .

The Use of Proj ect Tem plat es Tem plat es are t he building blocks for reusing sim ilar form s or docum ent s on different proj ect phase t asks of a proj ect . I n developing any docum ent at ion or assessm ent s for a proj ect , t he proj ect m anager sho uld invest igat e using t he following: St andard com pany t em plat es Downloaded t em plat es from t he I nt ernet Tem plat es developed from t he beginning Request ed t em plat es from special int erest groups PROJECT CON FI GURATI ON MAN AGEMEN T I have found, on num erous project s, t hat proj ect m anagers neglect t o m anage properly t he configurat ion of t he proj ect ( 1) docum ent at ion, ( 2) soft ware version, or ( 3) specific baseline. Most proj ect docum ent s used are eit her in a draft st age or have not been approved by t he client . Project m anagers share t he responsibilit y for st rict ly enforcing t he rule t hat a configurat ion ident ificat ion process be est ablished on t he proj ect , in order t o ident ify all proj ect baseline docum ent s. The em phasis here is t hat only approved baseline docum ent s wit h associat ed version cont rol shall be used on t he proj ect . Docum ent s should be able t o be t racked based on t he different version used. The risk t hat is run by using unapproved proj ect docum ent s relat es direct ly t o t he fact t hat t he proj ect t eam ut ilizes t hose docum ent s t o develop specific deliverables. The t eam m ay only find out lat er t hat t he client rej ect ed t he deliverables because t he client did not agree t o t he docum ent s in t he first place or did not review t hem com plet ely. The result can be slippages in schedule and cost for t he proj ect . Last ly, t he proj ect m anager needs t o insist upon and develop a m et hod for t he effect ive dist ribut ion and cont rolled releases of docum ent at ion and source code t o t he proj ect t eam individuals or groups. The proj ect m anager norm ally em ploys a configurat ion m anager or adm inist rat or on t he proj ect t eam t o ensure t hat t hese necessary form al configurat ion reviews are execut ed and carried out on a regular basis t hroughout t he proj ect life cycle. The t eam m em bers perform ing t he configurat ion reviews will be able t o inform t he proj ect m anager or proj ect office of t he num ber of change request s for t he proj ect , t he num ber of problem s, and how well configurat ion m anagem ent is being applied on t he proj ect . The proj ect m anager should ident ify t hat proj ect s t ypically need t he following baselines:

Functional baseline Allocated baseline Design baseline Product baseline What happens when t he client decides t o change a requirem ent aft er t he t eam has st art ed work on t he proj ect ? Many project s sim ply accom m odat e t hose change request s int o t he proj ect and t he work cont inues, irrespect ive of t he slippage or effect s t hat could occur lat er on. The solut ion t o t his scenario is for t he proj ect m anager t o insist on est ablishing a change cont rol process on t he proj ect for t hese change request s, and t he full t eam should be m ade aware of how t his change cont rol process works. The change cont rol process m ust have a m echanism in place for approving, rej ect ing, or pending change request s. These change request s should be fully evaluat ed t o det erm ine t heir im pact on t he overall proj ect before any decisions are m ade about t he request ed change. Let 's assum e t hat a change has been approved for a m inor m odificat ion t o t he proj ect , and it is approved wit hout an assessm ent being perform ed. Lat er on, it is discovered t hat t he t raining m anuals and Com put er Based Training ( CBT) courseware were not addressed when t he change was approved, and t his could result in t he delay of t raining. Figure 3.6 reflect s t he flow of change request s t hat would occur during t he proj ect . I t is im port ant for t he proj ect m anager t o realize t hat all proj ect change docum ent at ion is kept at t he proj ect level. Once all t est ing has been com plet ed on t he proj ect , proj ect m anagers obt ain t he necessary change docum ent at ion ( change request s, et c.) from t he proj ect office environm ent . Table 3.7 shows t he configurat ion it em s t o be placed under cont rol on a proj ect .

Figure 3 .6 : Managing change on t he proj ect

Ta ble 3 .7 : W hat proj ect it em s t o ident ify and pace under configura t ion cont rol Proj ect - Specific I t em s

Soft w a re- Specific I t e m s

Proj ect m anagem ent plan

Legacy dat a from t he client

Soft ware m anagem ent plan

Process specificat ions

Funct ional specificat ions

I nt erface specificat ions

I m plem ent at ion plan

Source code and script s

Operational user m anuals

Dat abase descript ions and schem as

Change request s

Prot ot ypes

Report s

Com m ercial off- the- shelf soft ware

Minut es of m eet ings LESSON S LEARN ED FOR PROJECT CON CEPTS Many proj ect s go disast rously wrong when t he proj ect m anagem ent m et hod is abandoned in order t o respond t o senior m anagem ent pressure t o speed up t he proj ect . The following are som e lessons learned: The init ial proj ect definit ion docum ent has no reference t o t he exist ing t echnology or proj ect anym ore. The proj ect plan does not t ake int o account t he risks of int egrat io n wit h exist ing syst em s. I nvolvem ent of ot her part ies was not previously ident ified as part of t he proj ect . I nt erfaces t o exist ing syst em s are being raised as an issue during t he last st ages of t he proj ect .

Ch a pt e r 4 : Th e Pr oj e ct An a ly sis PROJECT AN ALYSI S Most proj ect s t hat fail do so largely because of ineffect ive analysis and poor est im at ion during t he init ial build - up phases of t he proj ect . Therefore, it is essent ial t hat t he proj ect t eam perform a proper analysis upst ream . The rat ionale is t hat a good analysis and requirem ent sgat hering exercise save count less hours and change request s lat er in other proj ect life cycle phases. I n m any I T- relat ed proj ect , it is crucial t o ident ify and docum ent exact ly what t he client requires prior t o beginning developm ent . Rem em ber t hat good processes lead t o good proj ect s, allowing proj ect st aff t o be m ore focused and product ive. Bad processes lead t o rework and inaccuracies, t hus causing t he proj ect t o fail. By reading t his chapt er you will obt ain t echniques and guidelines for analyzing a proj ect and knowing what needs t o be done. This chapt er provides a road m ap of who perform s t he analysis and what needs t o be analyzed before launching a proj ect . I t is likely t hat you, t he reader, m ay feel t hat analysis has not hing t o do wit h proj ect m anagem ent at all; however, it is m y opinion t hat analysis is very m uch needed, and proj ect m anagers need t o include t he analysis or proj ect definit ion phase int o t heir proj ect life cycle. The choice of where t o st art wit h t he analysis of t he proj ect is an im port ant one, and it is one t hat needs t o be carefully considered. I n fact, I also believe that an in - dept h underst anding of t he inform at ion t echnology is j ust half of what is required t o respond t o client s' needs t oday. The ot her half is a t horough underst anding of t he ( 1) client 's business processes, ( 2) available dat a, and ( 3) client requirem ent s. The St ar Trek show Voyager provides an int erest ing m et aphor for t he challenges of a "proj ect analysis." During one episode, t he charact er Janeway, who is t he capt ain of t he Voyager spaceship, and her crew are t hreat ened by t he resilient "Borg," a dest ruct ive hum anoid species. Janeway inst ruct s her m edical and t echnical t eam s t o ident ify and develop a nano- virus, which will be int roduced wit hin t he Borg collect ive. I m m ediat ely, t he Voyager crew j um ps int o act ion, collect ing dat a, perform ing various sim ulat ions and feasibilit y st udies, racing against t im e. Event ually, t he ship's holographic doct or finalizes t he report m akes a recom m endat ion t o Janeway. I n a few short scenes, t he virus is int roduced int o t he Borg, and t hey are defeat ed! The analysis proved t o be correct . This elegant but sim ple allusion shows t he ent ire issue of perform ing a proj ect analysis: t he quest ion of whet her t he proj ect m anager will be

successful. So t oo, I T proj ect s need t o rely on a proper analysis for any prospect ive concept or idea. The concept phase, t herefore, is t he st age at which t he t eam recognizes t hat a proj ect should begin and com m it s t he com pany t o doing so. During t his phase, t he proj ect t eam det erm ines t he proj ect 's m ission, goals, obj ect ives, and scope in order t o develop a proj ect chart er and proper feasibilit y docum ent at ion. This docum ent at ion is t hen given t o t he execut ive t eam for approval, aft er which point , t he proj ect can com m ence. Table 4.1 shows which of t he core business analysis t asks t o com plet e. Ta ble 4 .1 : I ssues addressed in t he a na lysis a nd a ssessm ent phase Assess and Det erm ine

Rationale

Core business processes

To assist in t he business analysis

I nform at ion flows t hat support t hose processes

To underst and t he inform at ion flow

I nt eract ion bet ween processes and t he funct ional organizat ion

To det erm ine int erdependencies

What t he process and dat a owners say t hey require

To est ablish business case

Proj ect Analysis and Assessm ent Execut ives norm ally require som e form of business analysis t o be perform ed on a proj ect in order t hat t hey m ay obt ain a sum m ary of t he benefit s and im plicat ions of t he int ended proj ect . The business analysis is t he m echanism by which proj ect s are approved. I n t he m aj orit y of cases, a proj ect m anager is t asked or appoint ed by execut ives t o analyze t he feasibilit y of t he int ended solut ion and t o m easure t he business im pact . Depending upon t he scale and com plexit y of t he proj ect , t he proj ect m anager has t o consider who will be doing t he act ual business analysis. There are several possible resources who could perform and execut e t he business analysis. The proj ect m anager could perform t he business analysis t ask. The proj ect m anager could delegat e t he t ask t o a business or syst em s analyst .

The proj ect m anager could appoint ext ernal resources t o perform t he t ask . Ana lysis Ta sk s The business or syst em s analyst ident ifies, researches, collect s, and analyzes all required client dat a and inform at ion pert inent t o t he proj ect . The following t asks are exam ples of t hose t hat are perform ed by t he business or syst em s analyst : Docum ent ing execut ive high- level sum m ary Est im at ing value ret urn for each dollar spent Det erm ining t he pay back period of t he proj ect , also known as t he ret urn on invest m ent ( ROI ) Det erm ining t he feasibilit y of t he proj ect List ing all com pet it ive t hreat s and risks List ing regulat ory requirem ent s t hat could influence t he proj ect Det erm ining t he est im at ed num ber of client s t he proj ect will cover or influence Det erm ining t he ant icipat ed growt h of t he client base aft er proj ect im plem ent at ion Determ ining a cost est im at e for proj ect im plem ent at ion Predict ing operat ing cost s aft er proj ect im plem ent at ion Det erm ining t he capacit y planning needed for any I T hardware or net work There is significant responsibilit y when assum ing t he role of business analyst on a proj ect , as t he ent ire proj ect will base m any of it s finding and conclusions on t he analysis t hat is perform ed. I nit ially, t he analyst s m ay feel excit ed or t hat t hey are in "em ot ional overdrive," as t hey work on defining t he purpose of t he proj ect , clarify goals, m eet t he user com m unit y for t he first t im e, and m any m ore t asks. Aft er t he brief rush of a proj ect kicking off, m any proj ect m anagers and analyst s lose t he abilit y t o t hink "out -o f- the- box," oft en t o t he det rim ent of bot h t he client and t he proj ect . Clear- cut , yet creat ive, processes and analyses need t o be est ablished in order t o com plet e t he work. Today, it is even m ore crit ical t hat bot h proj ect m anagers and analyst s are creat ive

and are able t o package t he analysis in such a way t hat it provides a forecast of fut ure result s. Som e caut ion is ext ended t o analyst s and proj ect m anagers who fabricat e result s during t he analysis phase due t o a lack of sufficient dat a. The only way t o provide value t o any proj ect is t o be t rut hful, realist ic, realist ic, and fut urist ic. The out com e of t he analysis clearly indicat e t he current client st at us and provide client s wit h recom m endat ions wit h new ways t o do business. Rem em ber t hat a poor analysis will event ually result in t he failure of a proj ect . I dent ifying t he Proj ect Scope The proj ect scope is developed by t he proj ect m anager and basically defines t he product s and deliverables t o be produced during t he proj ect . The proj ect scope t akes t he input s from t he user requirem ent s and business case, and it st ruct ures t he proj ect int o exact ly what needs t o be perform ed. I n ot her words, it docum ent s what t he int ended business goals are. A com m on problem encount ered wit h proj ect scope is t hat t he m aj orit y of init ial client discussions and negot iat ions t ake place wit h t he client and m arket ing execut ive and are carried out in isolat ion from t he solut ion t eam . The ult im at e goal of m arket ing execut ives is t o m arket and sell solut ions t o client s, and when a solut ion is agreed upon, t he client is left wit h t he belief t hat it will get t hat specific solut ion. However, t he t echnical det ails are left up t o t he solut ion t eam t o resolve, and in m any cases, t he scope of t he proj ect changes. The proj ect m anager should work closely wit h t he m arket ing m anager and business analyst in order t o negot iat e t he com plet e scope of work. Rem em ber t hat if t he scope is left unt ouched and uncont rolled, it is probable t hat your proj ect will com e in over budget and behind schedule? I t is im port ant t hat t he proj ect solut ion t eam m eet wit h t he client wit hin a few days t o init iat e t he kick- off m eet ing and st art defining t he scope in m ore det ail. This is where t he business analyst s and proj ect m anager st art playing a valuable role by providing t he appearance, t he knowledge, and t he com m it m ent t o assist t he client in solving it s business problem s. The proj ect analysis t eam should include t he client as part of t he t eam in order t o verify t hat t he scope is defined accurat ely. One way t o present t he proj ect scope is t hrough t he use of t he proj ect m anagem ent plan or definit ion report . I t s purpose allows st akeholders t o det erm ine quickly if a given requirem ent should possibly be im plem ent ed by t he proj ect . I rrespect ive of which docum ent t he proj ect m anager decides t o use, t he following should be identified: What t he proj ect scope is

What t he proj ect is not How it will be m anaged The risks of scope change How scope changes will be int egrat ed int o t he proj ect I t is very likely t hat m ost proj ect s will have som e degree of scope change during t heir life cycle. Proj ect m anagers should clearly underst and what is included or excluded from t he proj ect , and what t his effect will likely have on t he ent ire proj ect . TH E AN ALYSI S ROLE PLAYERS I t is crucial t hat t he roles and responsibilit ies of t he people involved in t he init iat ion phase be ident ified and t hat all m em bers clearly underst and what is expect ed from t hem . I n t he following pages, I show t he t ypes of people who are needed on a proj ect init iat ion phase and what t hese resources are expect ed t o deliver t o t he proj ect . The Bus iness Analyst The business analyst is a necessary resource for virt ually any proj ect . I n t he m aj orit y of cases t here are t wo groups of people who fully appreciat e t he role of t he business analyst : ( 1) t he users for whom t he solut ion is being designed and ( 2) fellow business analyst s. Their relat ionship wit h t echnical developers is confusing at t im es, as t he t wo groups oft en bat t le over what act ual requirem ent s t he users need and what needs t o be developed. This is oft en a cause for m is- com m unicat ion and conflict. The proj ect m anager t herefore needs t o facilit at e t his process and keep t hese groups focused. The t asks of t he business analyst s are t o List en and focus on t he user requirem ent s in order t o reflect t he best int erest of t he business Gat her inform at ion and perform ext ensive research t o support user requirem ent s Analyze and t ranslat e user request s int o well- defined docum ent s, which t he developm ent group can use and underst and. These docum ent s could eit her be a ( 1) business case, ( 2) user requirem ent st at em ent , or a ( 3) t erm s of reference. Develop process flows, business rules, and procedures t hat support t he user requirem ent s Recom m end solut ions t hat m eet t he needs of t he business

The Syst e m s Ana lyst Syst em s analyst s are im port ant resources t o have on any proj ect t hat involves com plex, t echnical I T syst em s. They have considerable knowledge in inform at ion t echnology and are able t o com m unicat e bot h writ t en and verbal inst ruct ions. Before deciding t o em ploy a syst em s analyst , it is im port ant t hat t he proj ect m anager first underst and what t he syst em s analyst can cont ribut e during an analysis phase of a proj ect . Syst em s analyst s perform t he following roles: They assist in det erm ining syst em resource requirem ent s. They direct t he work of t he program m ers or fellow syst em s analyst s. They develop funct ional and t echnical analysis for large proj ect s or syst em s and provide recom m endat ions t o t he developm ent m anager or proj ect m anager. They review and develop flowchart s and dat a m odels from which applicat ions will be developed, com piled, t est ed, and im plem ent ed. They assist in developing procedures for an applicat ion. The Proj ect Manager or Proj ect Consult ant The proj ect m anager is t he leader of t he proj ect t eam and also cont ribut es during t he analysis phase of t he proj ect . Proj ect m anagers perform t he following t asks: They m anage t he init ial proj ect t eam m em bers assigned t o t he analysis phase. They resolve possible conflict s and com m unicat ion problem s bet ween st akeholders. They m anage t he proj ect schedule and delivery of business docum ent at ion and processes. They respond t o a client 's needs during t he analysis phase. They achieve t he obj ect ives of t he business. They m anage client expect at ions.

The Program Manager Unlike a proj ect m anager, who m anages a single proj ect or a few subproj ect s, t he program m anager is account able for t he coordinat ion and int egrat ion of all proj ect m ilest ones and act ivit ies t hat are int erdependent on one anot her. The program m anager usually has st rong organizat ional and leadership skills, and t hese skills help ensure t hat t he program will achieve it s int ended goals. The program m anager has a direct relat ionship wit h t he proj ect sponsor and individual proj ect m anagers. The Subj ect M at t er Expert The proj ect t eam oft en includes key proj ect t echnical m em bers and subj ect m at t er expert s ( SMEs) . Subj ect m at t er expert s bring expert or t echnical assist ance t o t he proj ect . Team m em bers should be list ed in t he proj ect chart er t o est ablish t heir roles and com m it m ent t o t he proj ect . Table 4.2 list s t he t echnical support t hat a proj ect m anager should arrange t o assist wit h t he t asks of t he business analysis phase. Ta ble 4 .2 : Technical t eam support during t he analysis phase Act ivit y Output Advise proj ect m anager on t echnology st rat egy

Offer t echnical advice and recom m end st rat egy

Review current archit ect ure

Review and docum ent findings

Plan and m ot ivat e for t echnology

Offer t echnology support and m ot ivat ions

Design t he fut ure t echnical archit ect ure

Est ablish t he fut ure t echnical archit ect ure

Build and assem ble t he t echnical solut ion

Build and present t he feasibilit y of t he solut ion

The End- user The end- user usually represent s t he client who will be using t he solut ion once it is im plem ent ed. The analyst s t herefore need t o m eet wit h t he end- user on a regular basis t o det erm ine t heir own respect ive requirem ent s. Norm ally, t he m ore knowledgeable t he user is, t he m ore likely key inform at ion w ill be included. Furtherm ore, leaving the end- user out of t he analysis phase can lead t o last m inut e design changes by t he developm ent t eam , as im port ant funct ional issues could be resolved by list ening t o t he day- to - day workings of t he user.

I t is advisable t hat during t he analysis phase of t he proj ect , t he analyst s obt ain a list of select ed end- users from t he client so t hat t he business or syst em s analyst s m ay have an idea of wit h whom t hey can work. These end- users event ually will be t he individuals facing t he quest ions and will be included in necessary business m eet ings. OBTAI N I N G PROJECT REQUI REM EN TS One of t he m ost im port ant st eps in any proj ect is t o det erm ine accurat ely what t he client requirem ent s will be. I t 's kind of like preparing a shopping list before going out shopping. Any m issing it em s from t he shopping list will have a direct influence on t he end result . Sim ilarly, on a proj ect , it is vit al t hat all t he necessary client requirem ent s be defined during t he analysis phase in order t o m ove forw ard. The biggest risk in not obt aining and approving all t he proj ect requirem ent s up front occurs when t he client st art s changing or adding addit ional requirem ent s t o t he scope of t he proj ect . These changes obviously have an effect on pricing, resources, and schedule. So t he key fact or here is t o ascert ain exact ly what needs t o be done. This is why m any I T proj ect s em ploy t he services and skills of t he analyst , who is a specialist in det erm ining t hese requirem ent s. A com m on m ist ake t hat proj ect m anagers m ake is t o com m ence work on t he next phase of t he proj ect before obt aining com plet e or approved business requirem ent s. Revision upon revision of user requirem ent s m ay have been developed, but som ehow t hese requirem ent s cannot be agreed upon. Nonet heless, t he proj ect m anager needs t o insist upon a com plet ed User Requirem ent Specificat ion ( URS) before cont inuing t he proj ect . I n m any cases t he client has not been involved during t he analysis, and t he end result is t hat t he deliverable differs from t he client expect at ions. The client , accordingly, will not sign it off unt il t he appropriat e revisions have been incorporat ed int o t he URS. This delay can t ake weeks, if left unm anaged, and, at t his st age, t he proj ect m anager should be focused on finding ways t o ensure t hat t his deliverable can be com plet ed. I dent ifying Business Requirem ent s The business requirem ent s need t o be present ed in a well- st ruct ured docum ent , which form s t he foundat ion whereby t he qualit y assurance and t est ing t eam s accept t he syst em . I deally, t he out com e is t hat t he funct ional requirem ent is a docum ent t hat shows clear consist ency bet ween what is t echnically possible ( wit hin realist ic t im e scales and cost ) and what t he business want s. However, t here are a num ber of different scenarios t hat can arise. I t is not possible t o be sure t hat t he requirem ent s are t echnically feasible, t herefore requiring prot ot yping.

The client requirem ent grows t o an unaccept able level of com plexit y, and t he proj ect conduct s a review t o see if t he proj ect can be split int o sm aller, m ore m anageable subproj ect s. There is only a part ial m at ch bet ween t he requirem ent s and what is possible, requiring a feasibilit y st udy t o explore t he degree of m at ch. Because m ost proj ect s are driven by t he funct ional specificat ion it is vit a l t o rem em ber t hat any change in t his specificat ion aut om at ically im plies a likely change in schedule and cost . Therefore, t he funct ional specificat ion is t o be well- docum ent ed and approved by t he relevant proj ect st akeholders. Once approved, t he specificat ion form s t he baseline by which t he proj ect will develop t he solut ion. The proj ect m anager m ust underst and t hat t he cost of changing t he funct ional specificat ion increases subst ant ially as t he proj ect progresses t hrough t he various phases of it s life cycle. I m agine working on a proj ect wit h an unsigned business requirem ent docum ent and t hen t he client inform s t he proj ect t hat it is not what t he client needed. The effect on t he ent ire proj ect is disast rous. Therefore, it is im perat ive t hat t he client confirm s and approves t he business requirem ent s. AN ALYSI S TECH N I QUES USED ON AN I T PROJECT I n t he course of any I T proj ect , it is very likely t hat t he proj ect m anager will need t o perform an analysis in order t o docum ent a solut ion for a client . I t m ay be necessary t hat t he business analyst s or relat ed proj ect t eam m em bers spend a considerable am ount of t im e wit h t he client ident ifying and gat hering all t he necessary inform at ion. I n t his sit uat ion, t here are m any levels of det ail t hat need t o be discussed, but t he following t echniques and issues m ust be addressed during t he analysis phase: I nquiry as t o whet her all t he dat a and inform at ion are available for analysis Det erm inat ion of how t he client current ly deals wit h t his current problem Review and docum ent at ion of t he current syst em I nquiry as t o whet her appropriat e t im e scales have been allocat ed for t he analysis phase Present at ion of alt ernat ive solut ions Ent it y relat ionship diagram s

Work and dat a flow diagram s I nt erviews held wit h users, suppliers, and com petitors Personal observat ions Quest ionnaires dist ribut ed t o ident ified t arget groups Research perform ed using t he I nt ernet , libraries, and special int erest groups SWOT analysis Ent it y Relat ionship Diagram ( ERD) Technique I n t he I T environm ent , it is at t im es necessary for analyst s t o use an ent it y relat ionship diagram ( ERD) t o docum ent and m odel organizat ional inform at ion needs. Som et im es narrat ive descript ions cannot be used, as it can be difficult t o visualize t he vast am ount s of dat a and processes in a t ext ual form at . The ERD allows t he analyst t o visually m odel t he organizat ion's inform at ion needs during t he early st ages of t he SDLC. When const ruct ing an ent it y, t he proj ect m anager writ es t he ent it y's nam e ( i.e., Cust om er or Em ployee) int o rect angular boxes, which denot e t hem as ent it ies. Anot her class of obj ect in an ERD is a relat ionship. Ent it ies are also associat ed by relat ionships t hat represent real- world relat ionships ( see Figure 4.1 ) . The following are som e t ips for using ERDs: Ent it ies are obj ect s about which t he syst em needs t o record inform at ion. Relat ionships are recorded on t he diagram as verbs and are represent ed by a diam ond shape.

Figure 4 .1 : Basic ent it y relat ionship diagram W orkflow Process Technique Before st art ing any proj ect , it is highly likely t hat t he analyst will sket ch or m odel som e process ( using m edia such as paper or com put er) . This is an im port ant part of any I T proj ect : I ssues becom e very com plex lat er on if t here is no m odel t o work from . The workflow process t echnique, in essence, describes how individuals com plet e t asks in order t o achieve a result or process. I t basically det ails how individuals com m unicat e and int eract t hroughout t he business process, as organizat ions t oday are

focusing on inform at ion and t he physical int eract ions bet ween t he m arket place and em ployees. When t rying t o analyze an organizat ion's current or fut ure st at e, analyst s m ust focus on t his wider view. The result of t his focus is an analysis t hat is based around int errelat ed organizat ional processes rat her t han j ust funct ional hierarchies, which is a good t hing. The workflow process m odel aim s t o capt ure t his collaborat ive process in a visual way, represent ing all variables involved in it s com plet ion. The workflow process m odel uses circles t o represent people and squares t o represent art ifact s—bot h real and inform at ional. Lines indicat e t he flow of inform at ion and all elem ent s are labeled appropriat ely. Addit ionally, t he flow lines indicat ing t he t ransport m edium ( i.e., by hand, fax, e- m ail, t elephone, web, Personal Digit al Assist ant ( PDA) , et c.) are also labeled for clarit y. Figure 4.2 depict s an exam ple of a workflow process m odel.

Figure 4 .2 : A classic workflow process SW OT Analysis Proj ect m anagers and business analyst s alike all use t he SWOT t echnique ( St rengt hs, Weaknesses, Opport unit ies, and Threat s) in order t o assess and becom e fam iliar wit h t he proj ect 's overall posit ion in t he m arket in relat ion t o com pet it ors before t hey det erm ine a m edium - t o long- t erm st rat egy. The SWOT analysis result s are det erm ined by ident ifying all posit ive and negat ive fact ors relevant t o t he proj ect . The SWOT t echnique is usually developed in a t eam environm ent and all t eam m em bers part icipat e in and cont ribut e t o com plet ing t he SWOT analysis. Table 4.3 shows t he fact ors t hat could det er a proj ect from being successful.

Ta ble 4 .3 : I nt ernal and ext ernal analysis fact ors I nt ernal Fact ors ( St rengt hs & W ea k nesses)

Ext ernal Fact ors ( Opport unit ies & Threa t s)

Clients

Econom ics

Shareholders

Regulat ory and legislat ive guidelines

Com pet it ion

Technology

Corporat e cult ure

Corporat e polit ics

Organizat ional st ruct ure

Environm ent al elem ent s ( e.g., eart hquakes, t ornadoes, hurricanes) Figure 4.3 clearly shows t he form at of t he SWOT analysis t echnique.

Figure 4 .3 : SWOT analysis diagram Life Cycle Dem a nd Ana lysis ( LCDA) The business analyst should analyze and m easure t he ant icipat ed usage and dem ands on t he current inform at ion syst em ( or syst em s) and what t he likely dem and on t he new solut ion will be over t he next few years. A t echnique t hat works well for t his sit uat ion is t he life cycle dem and analysis ( LCDA) . The analyst reviews t he current syst em by st udying hist orical dat a t o proj ect back as far as possible ( e.g., going back five years) and t hen calculat ing t he dem and for each subsequent year t he syst em will be in use. The average can t hen be det erm ined and proj ect ions m ade for fut ure years. However, t he analyst m ust carefully

det erm ine t he fut ure "volum es" or "users" t hat will be likely be using t he syst em , and ensure t hat t his LCDA is not perform ed in isolat ion. The t echnique shows it s value m ost when t he result s ( obt ained from int erviews, surveys, I T adm inist rat ion) are displayed on a spreadsheet form at for easy reference and review. Table 4.4 gives a t ypical LCDA for a com pany t hat would like t o reflect t he ant icipat ed usage or dem and of a proposed product or solut ion. I n t his exam ple, a 16.6 percent average annual increase is ant icipat ed. Accordingly, t he analyst uses t his growt h fact or when assessing t he current and proposed ut ilizat ion. Ta ble 4 .4 : LCDA of a proposed I T solut ion Proj ect ed Life of Solut ion

1999

2000

2001

2002

2003

2004

User Dem and

1,500

1,875

2,030

2,300

2,900

3,200

% Change

0

25.0%

8.26%

13.30%

26.08%

10.34%

Average %

16.59%

Business I m pact Analysis I t is im port ant t hat t he business or syst em s analyst evaluat es which syst em s and funct ional areas will be affect ed by t he im plem ent at ion of a new solut ion. The analyst s have t o ensure t hat sufficient assessm ent s have been m ade and t hat t hese findings are accurat ely docum ent ed. I t would be unwise t o raise a red flag or m ent ion t hat a crucial business depart m ent was left out of t he assessm ent when t he proj ect has reached t he physical im plem ent at ion st age. Therefore, analyst s need t o conduct a t horough, m et hodical assessm ent t o det erm ine who m ay be affect ed and t he im pact t his m ay have on t he current infrast ruct ure and resources ( see Figure 4.4 ) .

Figure 4 .4 : Business im pact analysis diagram Analyzing t he Client Archit ect ure The business or syst em s analyst should analyze and docum ent t he client 's current inform at ion t echnology archit ect ure as part of com plet ing t he proj ect init iat ion phase. Oft en, t he business analyst faces t he problem t hat he or she lacks t he skills t o perform a t echnical assessm ent of t he client 's archit ect ure; in t his case, t he assessm ent needs t o be delegat ed t o an I T archit ect or syst em s analyst . The analyst should ensure t hat a com plet e invent ory of t he current syst em is docum ent ed and t hat t his docum ent at ion includes ( 1) hardware, ( 2) soft ware, ( 3) com m unicat ion, and ( 4) t he physical infrast ruct ure. The analysis should clearly indicat e whet her t he I T syst em s are ( 1) owned by t he client or leased t o independent cont ract or( s) , ( 2) com pat ible wit h t he current archit ect ure and plat form s, ( 3) becom ing obsolet e, or ( 4) suit able for t he overall direct ion and t rends of t he business st rat egy. There are several fact ors needed t o perform a proper technology assessm ent , and t hese fact ors can be separat ed int o t hree m ain cat egories.

Hardw are I m port ant elem ent s t o consider when addressing hardware needs include The Manufact urer Scalabilit y of syst em Operat ing syst em s support ed Useful / anticipated lif e Hard drive capacit y Make of hardware Model Year Cost Mem ory Maint enance agreem ent s Power requirem ent s Net work requirem ent s Mult im edia requirem ent s CPU speed Soft w a re I m port ant elem ent s t o consider when addressing soft ware needs include The m anufact urer Regist rat ion Abilit y t o be cust om ized Licensing purchase cost Make of soft ware Training requirem ent s Version ( e.g. Ver. 5.0) Annual licensing cost Hardware t hat it support s Year purchased Maint enance agreem ent s

I nfrast ruct ure I m port ant elem ent s t o consider when addressing infrast ruct ure needs include Physical locat ion Types of prot ocols ( e.g., X25, ATM) Type of facilit y Sit e leased or owned Locat ion size Equipm ent t ype Bandwidt h Annual operat ing cost Available space Telecom m unicat ions com pany Power requirem ent s Air condit ioning DEVELOPI N G TH E BUSI N ESS DOCUM EN TATI ON During t he early phase of t he proj ect , t he business analyst s will begin t he process of docum ent ing and form alizing all business requirem ent s int o a ( 1) business case, ( 2) user requirem ent st at em ent , or ( 3) t erm s of reference docum ent . I t is vit al t hat t hese docum ent s are com plet ed on t im e, and t hey need t o be approved by all st akeholders ( even t he users) before being used t o draw up t he proj ect docum ent at ion. The business docum entation is norm ally co - aut hored or writ t en by t he proj ect m anager and m anaged t hereaft er. The proj ect business docum ent at ion m ust clearly t ake int o account t he exact client business requirem ent s. The proj ect m anager should ensure t hat t he docum ent at ion is consist ent and does not conflict wit h any ot her requirem ent s. The business analysis rem ains focused on docum ent ing t he core business benefit s. I t should t ake int o account t he needs and preferences of syst em users. Finally, t he docum ent at ion should be unam biguous and should p rovide t he reader wit h only one pict ure of what is required. Proj ect docum ent at ion is essent ial t o any proj ect success. I am rem inded of a t im e when I received an e- m ail on a Friday aft ernoon inform ing m e t o perform a proj ect audit on a t roubled proj ect t he com ing Monday m orning. When I arrived on t he given day and inquired about t he st at us

and whereabout s of t he proj ect docum ent at ion, I was t old by t he assigned proj ect m anager t hat t here was none, as t hey never had any t im e t o develop all t he required docum ent s. This st at em ent gave m e t he im m ediat e answer: Lack of docum ent at ion led t o t he proj ect going offt rack. Table 4.5 shows t he benefit s for proj ect s t hat use proj ect docum ent at ion. Ta ble 4 .5 : Benefit s of having business docum ent at ion in place Docum ent at ion W it hout Docum ent at ion Est ablishes clear underst anding of t he proj ect .

There is no m et hod t o reflect changes t o a proj ect .

For m s a baseline for docum ent ing t he proj ect scope.

There can be legal disput es.

Allows for bet t er proj ect m anagem ent in phases.

Analysis is ineffect ive.

Used for post - proj ect reviews and audit s.

Com m unicat ion wit h client is ineffect ive.

Chart s form al com m unicat ion t o client and ot hers.

The result is confusion.

Busine ss Ca se As proj ect s are cost ly exercises, it is im perat ive t hat senior execut ives wit hin t he organizat ion approve spending m oney on t he proj ect prior t o undert aking t he init iat ive. The way in which t hey are m ade aware of t he proj ect and com m it t hem selves t o t his proj ect is t hrough t he business case. Wit hout a form al business case, t he proj ect is likely t o be cancelled wit hin a short period of t im e and will have result ed in a lot of wast ed effort . The business case docum ent t herefore defines and assesses t he proposed proj ect . The business analyst develops t he business case wit h help from ident ified groups, depart m ent s, and subj ect m at t er expert s, and cont inues t o updat e t he business case in paralle l while developm ent t akes place. The business analyst and proj ect m anager, t oget her wit h execut ive involvem ent , should review and refine t he business case int o a workable docum ent . A copy of t he business case is kept in t he proj ect file ( see Figure 4.5 ) .

Figure 4 .5 : Business case diagram User Requirem ent s St at em ent ( URS) The URS is cert ainly t he m ost im port ant docum ent t o be produced on t he ent ire proj ect and it is also drawn up early in t he proj ect . Of not e is t he fact t hat everyone m ust be aware t hat requirem ent s m ay change. The URS t herefore form ally st at es t he client 's full business requirem ent aft er in- dept h analysis of t he sit uat ion. Affect ed end- users, I T, and m anagem ent are involved from day one. I t is very im port ant t o underst and t hat t he URS describes t he problem and t he requirem ent , even before any developm ent t akes place ( see Figure 4.6 ) .

Figure 4 .6 : User requirem ent s st at em ent diagram The Request for Proposa l ( RFP) The RFP is writ t en by t he client and subm it t ed t o m ult iple cont ract ors for t heir review and subsequent bidding. The bid should t hen be broken down int o st at em ent s of work ( known as SOWs) for each WBS it em . I like t o t hink of t he RFP as t he "what " and t he SOW as t he "how." Personally, I don't like t o give away t oo m uch of t he "how" in a bid t o t he request ing client in case it is not successful. The reason is t hat som e client s have no int ent ion of using t hat part icular com pany at all: Receiving t he t echnical bids is a sure way of knowing how t o perform t he work t hem selves, or bet t er st ill, t o get anot her com pany t o do it for less, based on t he first com pany's approach. I t is also cust om ary t o see som e RFPs t hat ask for a WBS as part of t he ret urning bid. Adj udicat ion of com pet it ive bids is m ore difficult , but it allows t he client t o see t he different approaches t o solving t he problem at hand.

St at em ent of W ork ( SOW ) The cont ract or bidding for t he proj ect writ es t he SOW and uses t he RFP as a reference docum ent . The m ain point of t he SOW is t o define t he work and t o divide t he m ain deliverables and subsequent t asks int o m easurable it em s. An exam ple of t his would be describing all of t he t asks t hat t he cont ract or perform s. The SOW explains bot h t he m anagem ent and t echnical approaches t hat will be used t o m eet all proj ect deliverables. The SOW also includes key m easurem ent and perform ance crit eria wit h an em phasis on how report ing t o t he client will t ake place. I t is oft en t he case t hat t he client does not underst and t he full scope of t he work t o be done. However, when writ ing t he SOW, t he client expect s an underst andable plan t hat clearly st at es what will be delivered. The problem m any SOW docum ent s have is t hat t hey use vague language, t asks are not well- defined, and it does not clearly st ipulat e what t he cont ract or is expect ed t o do. D ETERM I N I N G PROJECT FEASI BI LI TY The proj ect should be defined during t his phase, and t he definit ion should show t hat t he proj ect will be conduct ed in a logical and proper m anner. Som e of t he core funct ions addressed during t his feasibilit y assessm ent include Business purpose Benefit / cost analysis ( pay back) Legal and regulat ory issues Training issues Scope and det ail Execut ives t oday rely on valuable financial inform at ion t o guide t hem in m aking m ore inform ed decisions about proj ect invest m ent s. The point of assessing any pot ent ial solut ion for an organizat ion is t o det erm ine if t he solut ion will be valuable, and t he analyst needs t o find out ways t o ensure t his happens. The following are exam ples of reliable inform at ion t hat proj ect m anagers can supply execut ives. The proj ect ROI is 170 percent . The pay back period is 2.5 years and can be accom plished fast er t han ant icipat ed. The probabilit y of success is great er t han 70 percent . The proj ect risks have been analyzed and are deem ed accept able.

Price Versus Cost So very oft en, I encount er proj ect m anagers who are not even sure about t he differences bet ween price and cost of a proj ect . Wit hout underst anding t his basic concept t he proj ect could be lost . I n basic t erm s, price is t he am ount of m oney t hat a client or st akeholder is willing t o give t he proj ect m anager in order t o receive som et hing from him or her. As a provider, t his can eit her in t he form of a product or a service. Cost , on t he ot her hand, is t he am ount of resources ( e.g., m oney, st aff, t raining, m at erials, and equipm ent ) t hat are consum ed in order t o produce t he delivered product s or services t hat t he proj ect has as it s result. What then is the relat ionship bet ween cost and price? Are we sat isfied if we are able t o m ake a reasonable profit on what we do for our st akeholders? Are we sat isfied if t he cost of doing a proj ect is less, by som e accept ed percent age, t han t he selling price? Benefit - cost Ana lysis ( BCA) Organizat ions oft en regard inform at ion syst em s expendit ure as cost ly and risky, and t hese I T invest m ent s direct ly affect t he budget s. Despit e t he im port ance and cost , m any I T invest m ent s appear t o go ahead wit hout t he use of norm al invest m ent appraisal and risk m anagem ent t echniques. One such t echnique used t o j ust ify I T proj ect s is t he benefit - cost analysis ( BCA) . The proj ect m anager and t he proj ect t eam perform t he BCA, as one person rarely has all t he expert ise t o com plet e a BCA. Perform ed during t he init iat ion phase, t he BCA essent ially weighs t he benefit s against t he cost s of a proj ect and is norm ally m easured in m onet ary t erm s. I f m onet ary values cannot be assigned, t hen relat ive values for benefit s and cost s can be used. I n sim plified t erm s the benefit cost analysis clearly shows t he proj ect m anager t he "dollar burn rat e." The purpose of a BCA is t o support bet t er decision- m aking. Proj ect m anagers can use t his t echnique t o calculat e for every dollar invest ed on t he proj ect , t he dollar am ount expect ed t o receive back. For exam ple, let 's assum e t hat t he m arket ing depart m ent expect s t o achieve result s of $50,000 on t he product and t he proj ect m anager has det erm ined t hat it will cost t he client $35,000 t o im plem ent t he proj ect . Forecast ed figures show a 70 percent probabilit y of t his occurring, and est im at ed profit s are proj ect ed at 20 percent . Table 4.6 reflect s t he scenario where a posit ive BCA is achieved.

Ta ble 4 .6 : Calculat ing t he benefit - cost a na lysis ( w hen profit is com put ed in num erat or) Assum pt ions

Form ula Applicat ion

Est im at ed Benefit s ( Sales) = $50,000 Probabilit y of Success = 70% or ( 0.7) Est im at ed Profit = 20% ( 0.2) Est im at ed Cost s = $35 ,000

BC = 0.2 [a ]

Not e: I f you rem ove t he est im at ed profit percent age from t he benefit cost rat io form ula t hen you calculat e your break even poin t . ( B/ C rat io = 1.0) . For t his t o happen t he form ula m ust cont ain revenue not profit . [ a] Where > 1.0: Profit able, benefit s exceed t he cost . Where < 1.0: Unprofit able, cost s are great er t han t he benefit s. Where = 1.0: Benefit s balance cost , neit her win or lose. This exam ple shows a benefit - cost rat io of 0.2. This im plies t hat for every dollar invest ed, t he client can expect t o receive 20 cent s. Which is no t a bad result ( 20% ret urn on invest m ent ) . Rem em ber t hat when a BCA has been perform ed and com pared t o an alt ernat ive BCA and t hey bot h com e out wit h sim ilar cost s and different benefit s, t hen t he BCA providing t he great est benefit s t o t he proj ect should be select ed. Accordingly, if bot h BCAs have sim ilar benefit s but different cost s, t hen t he BCA wit h t he lowest cost should be select ed. Calculat ing N et Present Value ( N PV) On any proj ect , it is im port ant t o know what t he present value of t he cont ract am ount will be, even if t he proj ect is scheduled over a few years. A t echnique available t o proj ect m anagers is t o discount fut ure dollar values, or calculat e t he NPV, which t ransform s fut ure benefit s and cost s t o t heir "present value." The NPV allows t he proj ect m anager t o det erm ine t he value of a dollar one or m ore years from t he dat e of t he calculat ion. The present value ( also referred t o as t he discount ed value) of a fut ure am ount is calculat ed by using t he following NPV form ula: P = F ( 1/ ( 1+ I ) n Where P = Present Value, F = Fut ure Value, I = I nt erest Rat e, and n = num ber of years.

Est im at ing Ret urn on I nvest m ent ( ROI ) Not hing beat s selling t he business case bet t er t han a decent ROI . Today m ore and m ore client s are asking what value t heir I T invest m ent dollars will bring t he com pany. Because t hey are aut horizing t he capit al t o fund a proj ect , t hey would like t o know what 's in it for t hem ! I ncreasingly, proj ect m anagers are now request ed t o inform t heir client s what t heir likely ret urns would be because t he project m anagers are m anaging t he proposed proj ect . Proj ect m anagers should ask t hem selves if t hey would want a dollar t oday or a dollar t om orrow! The following form ula shows how to calculate the ROI :

A Proj ect Scenario A pharm aceut ical client has assigned a proj ect m anager t o replace a com pany's aging syst em wit h a m odern e- com m erce application. The execut ive t eam t asks t he proj ect m anager t o perform a ROI , as t he proj ect will be a large undert aking for t he com pany. I m m ediat ely, t he proj ect m anager begins t o quant ify several t hings ( see Table 4.7 ) . Ta ble 4 .7 : Ca lcula t ing ROI Yr0

Yr1

Yr2

Yr3

Cost w it h N EW Solut ion

Proj ect [ a ]

Support

Support

Support

Hardware

$200,000

Web Soft ware

$300,000

$100,000

$100,000

$100,000

Proj ect I m plem ent at ion

$550,000

Support $300,000 $300,000 $300,000 TOTAL $ 1 ,0 5 0 ,0 0 0 $ 4 0 0 ,0 0 0 $ 4 0 0 ,0 0 0 $ 4 0 0 ,0 0 0 [ a] The com parison of t he init ial cost of t he new solut ion t o t he cost of t he current solut ion is not appropriat e because t he new solut ion will not be available unt il t he end of Year 0. The com parison of t he t wo solut ions is not m eaningful unt il t he new solut ion is com plet e. [ b]

Assum es t hat t he proj ect will be com plet ed by t he end of Year 0 and will be available st art ing Year 1.

Yr0

Yr1

Yr2

Yr3

Cost w it h Proj ect [ a ] Support Support Support N EW Solut ion [c] There are several opt ions for choosing t he discount rat e, such as t he cost of capit al ( e.g., borrowed from a bank) , t he rat e of ret urn of alt ernat ive proj ect s, or t he invest m ent yield rat e. Yr0

Yr1

Yr2

Yr3

Cost w it h CURREN T Solut ion

Support

Support

Support

Support

Dat abase Adm inist rat ors

$600,000

$600,000

$600,000

$600,000

Operat ional Support TOTAL

$800,000

$800,000

$800,000

$800,000

$ 1 ,4 0 0 ,0 0 0

$ 1 ,4 0 0 ,0 0 0

$ 1 ,4 0 0 ,0 00

$ 1 ,4 0 0 ,0 0 0

[ b] The Net $1,000,000 $1,000,0 $1,000,000 Savings if 00 Proj ect is Chosen N ow Calculat e t he Discount ed N et Savings—assum ing a rat e of 9% [c ]

Year 1: $1,000,000 ?1/ ( 1 + .09) = $917,431.19 Year 2: $1,000,000 ?1/ ( [ 1 + .09) ?1 + .09) ] = $841,679.99 Year 3: $1,000,000 ?1/ ( [ 1 + .09) ?1 + .09) ?1 + .09) ] = $772,183.48 N PV TOTAL: $ 2 ,5 3 1 ,2 9 4 .6 6 ROI Discount ed N et Savings at 9%

$2,531,2 94.66

I nit ial Cost of N ew Solut ion

$1,050,0 00.00

ROI

241%

( posit ive) The com parison of t he in it ial cost of t he new solut ion t o t he cost of t he current solut ion is not appropriat e because t he new solut ion will not be available unt il t he end of Year 0. The com parison of t he t wo solut ions is not m eaningful unt il t he new solut ion is com plet e. [ a]

Yr0

Yr1

Yr2

Yr3

[ b]

Assum es t hat t he proj ect will be com plet ed by t he end of Year 0 and will be available st art ing Year 1. [c]

There are several opt ions for choosing t he discount rat e, such as t he cost of capit al ( e.g., borrowed from a bank) , t he rat e of ret urn of alt ernat ive proj ect s, or t he invest m ent yield rat e. The ROI of t his proj ect exam ple is 241 percent , which m eans t hat t he financial benefit s exceed t he init ial invest m ent by 141 percent . I f t he ROI were 100 percent , t hen t he benefit s would equal t he cost of t he proj ect— t hereby breaking even. PROPOSI N G A SOLUTI ON There are num erous opt ions for recom m ending solut ions t o a client . Norm ally t hese include ( 1) com m ercial off- the- shelf solut ions ( COTS) , ( 2) t ailored solut ions, and ( 3) t ot ally new developm ent s. Each recom m endat ion does carry it s own set of risks, and t he proj ect m anager should be aware of t hese during t he design phase. Typically, t he following areas should be t aken int o account : The business and procurem ent st rat egies The business requirem ent s Potential products and suppliers The t rend is a m ove t oward great er functionality and flexibility in packaged soft ware and a reduct ion in be- spoke developm ent . I t is now also likely t hat t he solut ion com ponent s will be purchased from a num ber of suppliers t hat adhere t o open syst em s st andards. Addressing t he Solut ions Capabilit ies The business analyst m ust ensure t hat during t he init ial proj ect m eet ings and design reviews, t he analyst docum ent s all t he capabilit ies t he client expect s from t he new solut ion once operat ional. This is an im port ant st ep as m ost of t he planning will revolve around and focus on t hese requirem ent s. Typical exam ples of what a client should com m unicat e t o t he proj ect t eam include 97 percent syst em availabilit y seven days a week ( redundancy) Mont h- end report s wit hin t wo days of m ont h end

Rem ot e field access t o 2,000 agent s Two t erabyt es of disk st orage space Help Desk agent s t o be able t o support 50,000 inbound calls, e- m ail, and faxes Abilit y t o ret rieve subscriber cont ract and account s wit hin t went y seconds Rout ine backup of user files and off- sit e st orage of disast er recovery files Training needs Com m ercial Off- the - shelf ( COTS) Solut ions I n broad t erm s, t he furt her t he solut ion m oves from a st andard package t o a t ailored solut ion, t he higher t he risk in t erm s of cost , t im e, and perform ance, as developm ent work is involved. The proj ect m anager should consult wit h t he client t o help t he client underst and t hat a COTS solut ion m ay be t he preferred opt ion. A COTS solut ion can Significant ly reduce t he risk of failure Deliver benefit s sooner because, being done before, it can be im plem ent ed fast er Cost far less t han t ailoring a syst em and redesigning from scrat ch The proj ect m anager should assess each of t hese reasons individually against each pot ent ial business benefit , im plem ent at ion cost , and risk factors. I t is a good idea t o hold a design review wit h t he following proj ect t eam m em bers t o evaluat e and decide upon t he appropriat e I T solut ion: Developm ent m anager I T archit ect Syst em s analyst Dat abase or syst em s Adm inist rat or Operat ions and support st aff ( capacity and perform ance planning) I f t he proj ect m anager has t he opt ion of t aking t he packaged, st andard solut ion approach, he or she should be aware t hat t here are st ill risks t hat need t o be m anaged. These risks m ay include having t o m ake a long-

t erm com m it m ent t o t he supplier of t he st andard solut ion, which m ay const rain fut ure I T purchasing st rat egy. The propriet ary COTS package m ay be discont inued, or have insufficient funct ionalit y, which could leave t he client wit h a problem . Therefore, t he proj ect m anager and his or her t echnical t eam should always consider whet her a COTS package im plem ent at ion is t he best select ion. Adapt ing Exist ing Syst em s An opt ion t hat is frequent ly overlooked is t hat of adapt ing an exist ing syst em . This opt ion m ay offer short- t erm benefit s, part icularly while wait ing for t he release of a proven version of a packaged solut ion, and it is a pot ent ially low-cost , low - risk solut ion. However, adapt ing and cont inuing t o rely on an exist ing syst em does have som e risks. I t can cause invest m ent in pot ent ially redundant t echnology plat form s. I t can creat e a reliance on in - house syst em s m aint enance skills. I t can prevent t he im provem ent of exist ing business processes. Developing Cust om ized Solut ions Many organizat ions require unique cust om izat ion of available st andard packaged solut ions. This cust om izat ion is perform ed in order t o get t he best of bot h worlds, but t he result can be failure if t he proj ect cust om izes t he solut ion t oo m uch. The key crit eria here is t hat t he client m ust , at som e point in t im e, draw a line when deciding upon t he am ount of cust om izat ion. There are t wo m ain cat egories t hat a client should consider when want ing t o cust om ize a solut ion: ( 1) lim it ed cust om izat ion and ( 2) ext ensive cust om izat ion. Table 4.8 port rays t he im pact each of t hese choices have on a st andard applicat ion. Ta ble 4 .8 : I m pact of cust om izing a st andard package Lim it ed Cust om izat ion

Ex t e nsive Cust om izat ion

Allows design of t he user int erface

I s likely t o cause an increase in proj ect schedule and budget

Offers abilit y t o change cert ain docum ent at ion and report s

Causes growt h in t echnical com plexit y

Gives definit ions and changing of custom ized fields

Result s in poor qualit y of funct ional and syst em fit

Defines cust om ized business

Does not have effect ive

Ta ble 4 .8 : I m pact of cust om izing a st andard package Lim it ed Cust om izat ion

Ex t e nsive Cust om izat ion

processes

support from soft ware vendor

The m aj orit y of soft ware packages available on t he m arket t oday ( i.e., Siebel CRM, SAP, Oracle, et c.) feat ure som e level of cust om izat ion, and such proj ect s can be im plem ent ed successfully, based upon t ried and t est ed proj ect m et hodologies. However, where t he need for ext ensive cust om izat ion is ident ified, t his becom es anot her m at t er. Ext ensive custo m ization falls into a high- risk cat egory, and t he proj ect t eam m ay need t o consider ot her opt ions, such as developing new soft ware. The proj ect t eam , nevert heless, needs t o validat e t hat t he client requirem ent s j ust ify t he cust om izat ion as being realist ic. Developing N ew Solut ions Developing an ent irely new solut ion is always t he highest risk for any client or cont ract or, and it should not be st art ed wit hout a form al assessm ent and com plet ion of a ( 1) ROI , ( 2) BCA, and a ( 3) risk analysis. Depending upon t he com plexit y of t he solut ion, it m ay be appropriat e t o seek risk- sharing wit h t he client . There are several sit uat ions t hat j ust ify developing a new solut ion. There is not hing current ly available on t he m arket t hat m eet s t he client requirem ent s. The new solut ion offers crucial advant ages in st rat egic business areas. The proj ect has t he required skills and experience t o handle a nonst andard solut ion. I t st rat egically exceeds t he client 's com pet it ors. I t offers business advant ages t hat are sust ainable over t im e. Re- engineering t he process t o work wit h a st andard solut ion is not appropriat e or represent s a high risk. The new solut ion provides a clear m arket different iat ion. Out sourcing One of t he opt ions open t o proj ect m anagers is t o out source eit her ( a) part or ( b) t he ent ire proj ect t o an ext ernal cont ract or. There are a num ber of reasons why t his m ight look like an at t ract ive opt ion. The decision t o out source t o a t hird part y or cont ract or st em s from t he

realizat ion t hat t he skills and knowledge t o achieve a successful out com e do not , and should not , reside in t he client 's capabilit ies. I t is im port ant t o recognize t hat out sourcing does not reduce risk unless t he out source requirem ent s are clear t o bot h t he client and t he cont ract or. The cont ract or, on one hand, m ust provide t he necessary skills t o m anage such out sourcing cont ract s. The client , on t he ot her hand, m ust decide if it s inform at ion t echnology act ivit ies are not core com pet encies. The client m ust also decide if it is seeking t o lower it s long- t erm capital invest m ent , t hereby m oving unwant ed t echnical risks and m anagem ent problem s ont o a cont ract or who has t he capacit y t o deal wit h t hem . Even t oday, count ries such as China, I ndia, and t he Philippines possess im pressive ult ram odern I T infrast ruct ures, skills, and resources t o t ackle I T proj ect s, com plet ely offshore. Table 4.9 ident ifies som e of t he fact ors affect ing out sourcing. Table 4 .9 : Out sourcing I T t o cont ract ors Benefit s of Out sourcing

Disadvant ages of Out sourcing

Lower cost —cheaper t o develop or m aint ain

Legal disput es

Fast er developm ent —reduced t im e t o m arket

Addit ional adm inist rat ion due t o t ravel, m eet ings ?/ t d>

Skilled and cert ified I T resources Risk m anaged by out source cont ract or

Cont ract ual abuse

?/ t d>

Proj ect Go / N o Go Decision Aft er t he analysis and feasibilit y of t he proj ect have been com plet ed and verified for accuracy, t he execut ive t eam has an opport unit y t o review t he inform at ion t hat was gat hered during t he analysis phase. This execut ive t eam m ay sit as a com m it t ee, or an individual m ay m ake t he decision. The go/ no go decision will det erm ine whet her a proj ect is wort h pursuing. The following are som e t ypes of quest ions can be raised: Does t he proj ect or opport unit y have t he required funding or budget ? Can t he proj ect be delivered at an accept able business risk t o t he organizat ion?

What are t he chances ( e.g., 90 percent ) of delivering t he proj ect on t im e? Are t he appropriat e resources available t o perform t he proj ect , and, if not , can t hey be obt ained? When will t he client be expect ed t o proceed wit h t he proj ect ( e.g., 60 days, 120 days) ? What is t he likely ROI and est im at ed profit abilit y t hat can be expected on t he proj ect ? Rem em ber t hat it is up t o t he proj ect m anager t o ensure t hat t he business analysis of t he proposed solut ion is com plet ed and t hat it reaches t he decision m akers in t he organizat ion for a go/ no go decision. The following decisions can be m ade: The overall proj ect is approved and t he st art of t he next phase can com m ence ( GO) . The proj ect is ret urned as incom plet e unt il addit ional aspect s have been covered ( NO GO) . The proj ect is rej ect ed due t o t he result s st at ed wit hin t he analysis ( NO GO) . Analysis Kick - off M eet ing The proj ect m anager, t oget her wit h t he business analyst , should always insist on an init ial form al kick- off m eet ing wit h t he client and ident ified client st aff m em bers. The purpose of t he m eet ing is t o det erm ine t he requirem ent s of t he solut ion and t o docum ent expect at ions, goals, and success crit eria. The kick- off m eet ing should be conduct ed wit h init ial high- level proj ect st akeholders at t he beginning of t he proj ect . The out put of t he m eet ing is t o art iculat e m anagem ent obj ect ives, produce t he draft proj ect chart er docum ent , produce t he work breakdown st ruct ure, and est ablish t he st rat egic schedule ( see Figure 4.7 ) .

Figure 4 .7 : Proj ect kick-off m eet ing involvem ent

LESSONS LEARN ED D URI N G TH E AN ALYSI S PH ASE On any proj ect , t he m anaging risks and problem s could be sim plified if lessons could be learned from previous proj ect s ( see Figure 4.8 ) . The following list at t em pt s t o highlight som e of t hese problem s: Com plex proj ect s have a reput at ion of delivering benefit s lat e and com e in over budget . The m ost effect ive way of cont aining risk during t he st art up phase of the proj ect is t o use experienced and skilled people. Docum ent everyt hing. A set of com plet e docum ent at ion will m inim ize uncert aint y and ensure easier updat ing when m aking revisions t o eit her requirem ent s or est im at es. When dealing across organizat ional boundaries, always ensure t hat you define and clarify roles and responsibilit ies of t he proj ect ( i.e., who is responsible for what t ask) . The lack of support , confidence, or excit em ent on t he part of t he client or sponsor could be a sym pt om t hat som et hing is wrong. The business analysis should include averages and peaks in t he docum ent ed analysis when reviewing t he syst em . I f t he syst em is not designed t o m eet peak dem ands, t hen it will fail.

Figure 4 .8 : Overview of analysis t asks I W ish I Had Know n That The following risks highlight possible problem areas t hat could im pede or m ake t he overall proj ect m ore problem at ic. Proj ect m anagers need t o ask several quest ions in order t o avoid serious problem s. Does t he proj ect have com m it t ed analyst s? I s t here a proj ect m anager or analyst responsible for delivering t he business benefit s? I s t here an experienced proj ect m anager? I s t here an agreed upon analysis process? I s t here a det ailed plan for proj ect m anagem ent , including allocat ion of proj ect responsibilit ies, account abilit y, and aut horit y levels? Do proj ect st aff underst and and accept t he business obj ect ives and proposed t echnology? Do t he analyst s have experience docum ent ing and capt uring dat a? Have t he analyst s assessed sim ilar proj ect s before?

Consult at ion is needed not only wit h exist ing and pot ent ial users of t he system , but also wit h t hose who originat e and use t he inform at ion being processed. Are t he cust om ers and users of t he syst em com m it t ed t o t he analysis and result ing st at em ent of t heir needs? Phase Com plet ion Checklist The proj ect m anager should ensure t hat t he following proj ect docum ent at ion is filed wit hin t he m ain proj ect folder in order t o com plet e t he proj ect analysis phase: Client cont ract or let t er of int ent User requirem ent specificat ion Proj ect proposal Business case Term s of reference Feasibilit y st udy Proj ect work aut horizat ion Analysis worksheet s and dat a St at us report s Minut es of t he m eet ing Any inbound and out bound correspondence All final proj ect cost s, such as t im esheet s, invoices, and so fort h

Ch a pt e r 5 : Pla n n in g f or Su cce ss PLAN N I N G BEGI N S The core funct ion of t he proj ect m anager during t he planning phase is t o plan and provide a roadm ap for t he proj ect . Proper planning is t he cornerst one of a successful proj ect , while im proper planning is oft en t he prim ary cause of a failed proj ect . There are a few im port ant st eps t hat are part of planning a good proj ect . The prim ary focus of proj ect planning is t o ident ify t he following: What needs t o be done? How com plex is t he proj ect ? When it will be done? How will it be done? Who will be responsible for each t ask? What t ypes of deliverables will be needed? What skillset s and quant it y of resources are needed? How m uch will t he proj ect cost ? Early proj ect planning brings relevant issues, point s of disagreem ent , assum pt ions, and risks t o t he t able in order t hat t hey be resolved im m ediat ely. Because plans are est ablished early on in t he proj ect , t he proj ect m anager will face m any unknowns and m ust deal wit h t hem accordingly. These assum pt ions are always docum ent ed as part of t he plan. Lat er on, as t he assum pt ions are resolved, t he plan can be m odified appropriat ely. Aft er you have det erm ined your plans, cause t he officers t o know t hem . Knowledgeable officers can be t rust ed. Make rewards clear and t hen t he t roops will advance wit hout hesit at ion. —Sun Tzu Plann ing relies on t hree crit ical elem ent s: ( 1) good input , ( 2) good planning, and ( 3) proper allocat ion of needed resources. For t he proj ect m anager, planning is about deciding which act ivit ies have t o t ake place and when, as well as allocat ing resources t o allow t he m eet ing of deadlines. Can you im agine a proj ect being planned wit hout any prior specificat ions and blueprint s? I t hink not ! For over t en years, I have worked in I T proj ect m anagem ent on different t ypes of I T proj ect s. During t hat t im e, I developed m any different planning m et hods and t echniques t hat cont ribut ed t o t he success of a proj ect . I have also seen m any proj ect m anagers dive st raight int o t he

developm ent phase, developing soft ware or product s, wit hout t he appropriat e planning in place. When t he proj ect ran int o problem s, it was oft en t oo lat e t o t urn back, and t hese proj ect s oft en failed in som e way. I n cases where no planning was done, it becam e ext rem ely difficult t o reverse such a sit uat ion. I t is essent ial t hat a considerable am ount of t im e be spent planning a proj ect . I t is ext rem ely likely t hat t he proj ect m anager will be required t o double- check t he proj ect planning in order t o reflect last - m inut e changes and unforeseen circum st ances t aking shape on t he proj ect . A proj ect m anager can quickly det erm ine how difficult a t ask he or she will face based on t he result s of t he init ial planning. Figure 5.1 illust rat es a basic planning p r ocess.

Figure 5 .1 : Planning phase act ivit ies I dent ifyin g t he Proj ect Any proj ect being planned at t his st age needs t o be clearly ident ified and allocat ed a unique nam e ( e.g., Proj ect Aspen) or a sequent ial t racking

num ber ( e.g., P15724) by which all st akeholders can ident ify and reference t he part icular proj ect . The m ain reason for giving t he proj ect an ident ifier is t o ensure t hat any relat ed proj ect cost s ( in whichever proj ect phase) are clearly carried against t hat specific proj ect . Could you im agine t he effort involved in t rying t o explain t o a finance depart m ent which cost s should be carried against ? I doubt t his would be an easy t ask for any proj ect m anager or adm inist rat or. The benefit of being able t o t rack a proj ect is clearly evident . I t aids not only com m unicat ion, but also audit ing and archiving. Let 's assum e t hat a part icular proj ect is one of m any being m anaged for a cert ain client . Each year, t his client is required t o undergo a financial audit ing process. When a discrepancy is discovered on a specific cost it em , neit her t he audit ors nor the client are able t o t race t he it em t o t he correct proj ect . This m akes a com plex and t im e- consum ing adm inist rat ive burden for all involved. To t his end, assigning a nam e t o a proj ect is advised for any proj ect m anager. Keeping Things Sim ple Wherever possible, ask t he quest ion "How can we reduce t he com plexit y of t his proj ect ?" I n I T proj ect s m odifying exist ing syst em s and soft ware significant ly increases com plexit y and risk: A com plex proj ect t akes longer, and t his m akes it inherent ly m ore risky t han a sim pler one. One way t o gain a m easure of cont rol is t o break down soft ware requirem ent s int o sm aller, m ore m anageable pieces wit h defined out put s t o be delivered wit hin short t im e scales. When dealing wit h t he int egrat ion of various t echnologies as delivered by m ultiple suppliers, it becom es easier for t he proj ect m anager t o have one prim e cont ract or responsible for t he t ot al int egrat ion. Organizat ions are depending m ore on t heir I T syst em s t o achieve success. I t is t herefore vit al t hat new syst em s are int egrat ed int o t he business quickly and effect ively. However, successfully int egrat ing new I T syst em s wit h exist ing syst em s and business processes is one of t he key problem areas for m any organizat ions. I N I TI AL PLAN N I N G I n order t o est ablish t he init ial planning for t he proj ect and t o gain a bet t er underst anding of what needs t o occur, t he proj ect m anager needs t o obt ain all prior business analysis and reference docum ent at ion. The following are suggest ed st eps for basic planning: Creat e t he init ial proj ect m anagem ent plan. Det erm ine t he durat ion and level of effort of t he proposed work. Ensure t hat all const raint s and assum pt ions have been included.

Achieve consensus wit h st akeholders for all t asks and durat ions. Creat e t he init ial st affing requirem ent s. The m ain plann ing st eps t aken for proj ect planning also need t o be execut ed as part of t he overall planning. Table 5.1 list s t he m ain t asks t hat need t o be perform ed. Ta ble 5 .1 : M ain proj ect planning t ask s Plan Techniques Used Develop t he WBS

Funct ional proj ect decom posit ion, soft ware t ools

Det erm ine act ivit y dependencies

Proj ect net work diagram

I dent ify proj ect risks

Risk soft ware, assum pt ions

I dent ify proj ect m ilest ones

WBS

Est im at e t he effort

Resource usage spreadsheet s

Creat e proj ect schedule

WBS

Perform proj ect est im at e

Param et ric m odeling

W ork Breakdow n St ruct ure ( W BS) Tim e and t im e again, proj ect m anagers get caught up wit h t he not ion t hat every conceivable t ask should be included in t he developm ent of t he proj ect WBS. The end result is a big list of t asks t hat does not reflect what t he proj ect m anager will be doing. Building a WBS for a m aj or proj ect can be t im e- consum ing but well wort h it . I have seen m any proj ect m anagers produce wonderful and com plex WBS docum ent s t hat leave t heir seniors adm iring t he det ail and st aggering result s t he docum ent describes. Due t o t he com plexit y and t ype of int egrat ion t hat proj ect s require t oday, proj ect m anagers need t o rely on t he SMEs and t echnical specialist s because t here is no chance t hat t he proj ect m anager will t hink of everyt hing. Milest ones are t hose physical elem ent s t hat t he proj ect will deliver. The WBS should reflect t he m aj or proj ect m ilest o nes as well as t heir associat ed t arget dat es. Som e of t he possible deliverables a proj ect m anager should consider are proj ect plans and im port ant docum ent at ion ( e.g., billing specificat ion, user m anuals) and physical product s ( e.g., hardware, m odules, t raining, et c.) .

The WBS is a hierarchical grouping of proj ect elem ent s ( sim ilar t o a fam ily t ree) , st art ing wit h t he higher levels and breaking t hese down int o lower- level elem ent s. The WBS can be viewed in eit her t abular linear form at or in graphical form at . The underlying rule of t he WBS is t o break t he proj ect down int o sm all, m anageable part s, whereby owners for each deliverable are est ablished. Once t his has been com plet ed, t he proj ect m anager est im at es t he cost for each t ask ( see Figure 5.2 ) . There are six com m only used st eps used t o build a WBS. Det erm ine t he high- level phases of t he proj ect . Separat e t hese high- level phases int o det ailed work packages. Arrange t he t asks in logical order or sequence. Est im at e t he t ask durat ion and t he effort for each t ask. Review t he WBS wit h all st akeholders. I ncorporat e any changes t o t he WBS and baseline t he WBS.

Figure 5 .2 : The work breakdown st ruct ure ( WBS) chart Product Break dow n St ruct ure ( PBS) Oft en proj ect s are est ablished t o develop a specific product ( e.g., m obile phone) . The t echnique used t o ident ify and represent t he physical and

funct ional breakdown of a product is known as t he product breakdown st ruct ure ( PBS) . Wit hin t he syst em s m anagem ent world, it is known as t he bill of m at erials ( BOM) . I t is good t o be able t o develop a PBS for t he product , as t his will aid t he proj ect m anager in ident ifying m aj or deliverables for t he proj ect . Figure 5.3 is an exam ple of a PBS.

Figure 5 .3 : The product breakdown st ruct ure ( PBS) chart Proj ect Schedule Preparat ion ( Gant t Chart ) The developm ent of an overall proj ect schedule can be conduct ed using a Gant t chart , t he m ost com m only used t ool for displaying proj ect schedules. I t allows for a clear snapshot of t he proj ect at a glance. There are num erous proj ect scheduling soft ware t ools available on t he m arket t oday t hat allow t he proj ect m anager t o creat e a schedule, allocat e resources, and ident ify t he crit ical pat h. However, in creat ing t he Gant t chart , t he proj ect m anager needs t o underst and how t o creat e a basic chart . The m inim um inform at ion shown displayed on a Gant t chart consist s of: A horizont al t im e scale displaying t he proj ect by days, m ont hs, or years A list of proj ect act ivit ies and m ilest ones displayed vert ically on t he left- hand side of t he chart Allocat ion of m anpower and m at erial resources t o each act ivit y Proport ional bar indicat ing t he durat ion of each act ivit y indicat ed on t he horizont al axis

I have always found it useful t o follow som e process when developing t he Gant t or schedule, and I use a seven-st ep process t o assist m e in creat ing t he proj ect schedule ( see Figure 5.4 ) . Review t he proj ect calendar ( t o ident ify holidays, vacat ions, et c.) . Assess t he t im e const raint s on t he proj ect ( e.g., com plet ion dat e, dependencies, et c.) . St art sequencing t he t asks ( e.g., logical progression of t ask s) . Det erm ine t he resources needed ( e.g., ident ify skills, t echnologies, budget , et c.) . Est im at e t he t ask durat ion( s) and verify t im e involved per t ask. I dent ify t he short est rout e from st art t o finish bet ween t asks ( i.e., t he crit ical pat h) . Develop t he proj ect schedule using t he above st eps.

Figure 5 .4 : Preparing the schedule However, while preparing t he Gant t chart , it is im port ant t o underst and t he relat ionship bet ween proj ect act ivit ies. Dependencies t hat are incorrect ly est im at ed will influence t he ent ire schedule from now onward, and t he proj ect m anager m ay have t o st art t he schedule over. Rem em ber t hat t he relat ionship bet ween t wo act ivit ies is where one act ivit y depends on t he st art or finish of anot her act ivit y in order t o begin or end. The act ivit y t hat depends on t he ot her act ivit y is t he successor and t he t ask it depends upon is t he predecessor. Figure 5.5 shows t he dependencies com m only used when creat ing a schedule.

Figure 5 .5 : Defining t ask relat ionships I n t he process of developing t he proj ect schedule, it is com m on for som e proj ect durat ions t o be unknown, and guessing isn't ent irely accurat e eit her. Maybe t oo m uch padding has been added or t he durat ion has been reduced by t oo m any days or even weeks. This assessm ent is oft en unrealist ic and d ishonest . I n t he event t hat t he above values cannot be est im at ed, t hen t he proj ect m anager should rely on t he expert ise of t he SMEs t o assist wit h est im at ing t he durat ion. They will be able t o provide m ore accurat e values t o use in calculat ing t he average durat ion for a proj ect t ask. I n t his scenario, t he weight ed- average tim e technique is used in order t o det erm ine t he expect ed average durat ion for a given t ask. The form ula is as follows:

Proj ect s t hat exceed cost and t im e due t o bad est im at es can cause t he com pany t o face financial losses. The consequences include lost business opport unit ies and failure t o bringing t he product t o m arket ahead of t he com pet it ion. Accurat e est im at es reduce t he risk of proj ect overruns,

t hereby sharply curt ailing negat ive business effect s. This is why so m any businesses are relying on t he param et ric based est im at es. Accurat ely est im at ing proj ect cost s and schedules is vit al in det erm ining t he success of a proj ect . Arrow N et w ork Diagram Technique A t echnique t hat I have found t hat really assist s proj ect m anagers in sequencing proj ect act ivit ies, ident ifying gaps, and ident ifying possible dependency relat ionships is t he arrow net work diagram t echnique. I n m any cases, a proj ect m anager lit erally cannot see t he forest for t he t rees; problem s st art arising lat er on t he proj ect when he or she realizes t hat t here are, in fact , dependencies t hat had not been recognized, and t he sequence was done incorrect ly. Therefore, it is im port ant t o have a sim ple t echnique t o reflect dependencies in graphic form . However, t here are som e rules t o t his graphing t echnique. The net work diagram is always drawn from left t o right . I t is not drawn t o scale. An arrow represent s an act ivit y, wit h t he t ail indicat ing t he st art and t he arrowhead it s com plet ion. Arrows m ust follow t he sequence of t he work t o be done. The lengt h of t he arrow is not im port ant . The st art and end point s of an act ivit y are called event s and are represent ed by circles. The event s are usually labeled wit h a num ber ( 1, 2, et c.) . Br ok en- line arrows represent dum m y act ivit ies and show where one act ivit y depends on anot her. Using t hese rules, t he act ivit y net work is built t o allow for som e adj ust m ent s and refinem ent of t he net work where needed ( see Figure 5.6 ) . I t m ay be t he case t hat act ivit ies are eit her t o be delet ed or reassessed. The net work is built in t he following way. List all act ivit ies. Separat e t he proj ect int o a list of act ivit ies, depending upon t he size of t he proj ect and desired dept h. Use t he WBS as a reference t ool. Sequence t he act ivit ies. St art sequencing all t he act ivit ies in t heir correct order and include t he applicable act ivit y dependencies t hat

apply t o t hem . Rem em ber t o look at t hose act ivit ies t hat m ust be com plet ed before t he next act ivit y can begin as well as t hose act ivit ies t hat can st art at t he sam e t im e.

Figure 5 .6 : Arrow net work diagram Proj ect Crit ica l Pa t h I n essence, t he crit ical pat h is a t echnique for calculat ing t he t ot al durat ion of a proj ect based on a specified st art dat e and on t he individual durat ion of act ivit ies and t heir dependencies upon one anot her. Rem em ber t hat if t here is an act ivit y on t his crit ical pat h t hat get s delayed, t hen t he proj ect is delayed—pushing t he proj ect st at us int o red, and t hat is not where anyone want s t o be. For all t hose act ivit ies t hat are not on t he crit ical pat h, it m eans t hat t he proj ect m anager is okay and can be m ore flexible wit h t hose specific t asks. Underst anding exact ly how one get s t o a crit ical pat h is som ewhat t ricky. First , t he proj ect m anager needs t o creat e a well- docum ent ed net work diagram . There are a host of soft ware packages t hat can be used t o do t his, and som e creat e it very quickly. Once t he proj ect m anager has t he net work diagram , he or she sim ply adds each parallel pat h's act ivit ies t oget her; t he pat h t hat requires t he longest t im e t o run t hrough t he proj ect is t he crit ical pat h. This m eans t hat it is t he short est t im e in which t he proj ect can be com plet ed. Once t he proj ect m anager has det erm ined t he crit ical pat h, it is very im port ant t o m onit or t his pat h and underst and t hat , if t he act ivit ies st art slipping on t he crit ical pat h, it is highly likely t hat t he overall proj ect m ay st art failing. To reduce t he proj ect t im e, t he proj ect m anager should allocat e m ore resources t o t hose act ivit ies on t he crit ical pat h. PROJECT ESTI M ATI ON Predict ing t he out com e of any proj ect is difficult because t here are num erous m et hods for est im at ing what a proj ect would cost . Proj ect s t hat are sim ilar and have hist orical dat a are easier for t he proj ect m anager t o est im at e, com pared t o proj ect s t hat are uniq ue in nature and have never been at t em pt ed before. While t here is no such t hing as a reliable est im at e, t here are realist ic ones. An accurat e est im at e reduces t he risk of proj ect overruns, t hus sharply curt ailing negat ive affect s on business. Estim ating is a skill t hat im proves over t im e, and proj ect m anagers should not init ially at t em pt t o do any est im at ion work wit hout guidance from experienced proj ect est im at ors or cost account ant s. Wit hout accurat e est im at es, t he following scenario will occur:

Your pr oject will be behind schedule—t hus lat e. Your proj ect will be over budget —t hus have cost overruns. You will likely lose your client —because you can't m eet client expect at ions. The Est im at ion Process The proj ect m anager should rem em ber t hat t he est im at ion t hat result s from t he planning phase is not final and is considered a t em porary est im at e. Once m ore det ailed proj ect planning is perform ed and t he proj ect cost s and WBS schedules are fine- t uned, a m ore accurat e est im at e em erges. Basically, t he est im at ion process has a few prim ary st eps: 1. Develop t he WBS. 2. Est im at e each part of t he WBS const it ut ing t he t ot al proj ect . 3. Schedule t he work according t o each WBS t ask. 4. Det erm ine t he resources needed, quant it ies, and availabilit y. 5. Obtain the latest resource rates, inclu ding next salary reviews

and increases. 6. Det erm ine t he level of effort needed t o com plet e each WBS

t ask . Som et hing t hat is very im port ant during t he est im at ion process is t hat proj ect m anagers ask t he client t o pay a price t hat is relevant t o t he perceived value of what t hey receive. I f t he client is willing t o pay for t he proj ect , t he proj ect m anager needs t o det erm ine whet her it is profit able enough t o do t he work. To det erm ine t his, proj ect m anagers m ust det erm ine cost . This is where t he est im at ion is needed ( see Table 5.2 ) . Ta ble 5 .2 : W hat t o include in a proj ect est im at e Proj ect Cost Est im at e

Descript ion

I nt ernal labor or cost of em ployees

Burdened cost t o com pany— benefits included

Hardware cost s

Servers, print ers, workst at ions

Soft ware and licensing

Applicat ion soft ware, downloaded soft ware pat ches, code

Travel and accom m odat ion

Airfares, hot el, t olls, gas

Ta ble 5 .2 : W hat t o include in a proj ect est im at e Proj ect Cost Est im at e

Descript ion

Adm inist rat ive support cost s

Personnel, finance, and legal support

Training cost s

User t raining, com put er- based training, lesson plans

Syst em docum ent at ion cost s

Manuals, policy & procedures, online docum ent at ion

St at ionary cost s

Proj ect st at ionary

I nfrast ruct ure cost s

Office space, desks, rent , parking

Figure 5.7 illust rat es t he t ypical proj ect cost s t hat should be considered.

Figure 5 .7 : Consolidat ing proj ect cost s Est im at ing t he Effort I t is said t hat you cannot m anage what you cannot m easure. No m at t er what proj ect a proj ect m anager has been allocat ed or assigned t oo, t he proj ect est im at e should include t he following: Size of t he proj ect Resources required

Proj ect durat ion Cost s needed t o com plet e t he proj ect , labo r, hardware, t ravel, et c. Est im at es in t he I T indust ries are incredibly difficult t o com plet e due t o so m any unknowns. The init ial est im at e is, in m any ways, t he m ost im port ant . The init ial est im at e will be a focal point wit h which t he proj ect m anager can com pare all fut ure est im at es. Because of t his, t here are several recom m ended st eps t o follow when achieving an init ial est im at e. •

Break down t he proj ect requirem ent s as far as possible t o

•

subsyst em levels ( WBS) .

•

For each WBS elem ent , ident ify it s sim ilarit ies wit h previously developed proj ect s and use t his hist orical dat a.

•

For t hose WBS elem ent unit s not st rongly relat ed t o previous I T proj ect s, use SMEs t o est im at e t he size of t hose elem ent s needed.

•

Form t he size est im at e for t he ent ire proj ect by rolling up t he est im at es for all t he WBS elem ent s.

•

From hist orical dat a and expert ise, est im at e t he level of effort .

•

Divide t he size est im at e by t he work rat e t o obt ain an est im at e of t he effort in work hours.

Once t he WBS has been developed, m any proj ect m anagers m ove direct ly t o det erm ining t he durat ion of t he t ask. This is norm ally done using a soft ware t ool, and it visually appears as t hough t he proj ect m anager is on t he right t rack. This is not t he correct approach; it creat es room for errors and bad planning. Rem em ber t hat it t akes a lot of skill and experience t o est im at e all WBS t asks. For exam ple, it can t ake one seasoned I T archit ect a few hours t o do a server capacit y assessm ent , but t he sam e t ask could t ake t wo j unior I T archit ect s double t he am ount of t im e t o perform . Sim ilarly, a sit uat ion m ay arise where only one person can do a specific t ask, such as cloning a server. Only one resource can do t he specific t ask, not t wo. Therefore, in t his case, t he em phasis is on ensuring t hat t he resource is best - qualified t o perform t his t ask. The proj ect m anager also needs t o discuss t he issue wit h an SME t o det erm ine t he am ount of effort . The cost per t ask is direct ly relat ed t o t he resources and effort needed. The proj ect m anager m ust accom m odat e t he level of effort needed t o perform t he t ask.

Top- dow n Est im at ing ( Param et ric) The WBS form s t he basis of t he t op- down est im at ion t echnique. Here t he focus is on t he proj ect m anager ident ifying t hose proj ect param et ers t hat indicat e what t he proj ect resources will cost . This is an opport unit y t o break down t he cost s of t he proj ect from t he t op working downward, and t hus having a visual represent at ion of all proj ect values. Table 5.3 show s an exam ple of t op- down estim ation. Ta ble 5 .3 : Param et ric m odeling Descript ion of an I T Proj ect

Value

Java developers

( 100 hours ?$90 / hour)

$9,000.00

Syst em adm inist rat or

( 10 hours ?$60 / hour)

$ 600.00

Webm ast er

( 20 hours ?$80 / hour)

$1,200.00

Tot al Direct Cost —( The burdened labor cost is excluded—no benefit s, overheads included.)

$10,800.00

A

We now include t he burdened labor rat e if det erm ined t o be = 1.08

$11,664.00

B

Tot al Direct Cost for Proj ect

$ 22,464.00

A + B

Bot t om - up Estim ating This t echnique relies heavily on t he WBS approach. I t is a useful m et hod, oft en used due t o it s accuracy and abilit y t o roll up t he proj ect cost s from t he lowest level t o t he higher levels by referencing it against t he WBS. Bot h t im e and cost are allocat ed against each WBS it em , and SMEs provide specialist input . When t his process is com plet ed, t he cost s roll up t o each subsequent higher level. Event ually, a t ot al proj ect cost is det erm ined ( see Figure 5.8 ) . I t m ust be not ed t hat it can be difficult t o use t his m et hod on a proj ect where t he scope was not fully det erm ined ( i.e., Research and Developm ent —R&D project ) .

Figure 5 .8 : Bot t om up est im at ing Phased Est im at ing I t is probable t hat t he t echnological nat ure of m any proj ect s, such as R&D proj ect s, m akes it ext rem ely difficult t o est im at e t he ent ire proj ect effort accurat ely. I n t hese circum st ances, t he only approach st ill open t o t he proj ect m anager is t o provide a proj ect est im at e on a phase- by- phase basis. This is oft en difficult for a client t o accept , let alone underst and, as t he client requires t he com plet e proj ect dollar value for cash flow and budget ary purposes. To t his end, it oft en appears t o t he client t hat t he proj ect t eam is unwilling t o accept t he proj ect risk. Phased est im at ing can act ually be in t he client 's best financial int erest due t o t he fact t hat t he client is now able t o review each proj ect phase at specific int ervals. I n realit y, t he client rem ains in full cont rol and could eit her st op or rej ect t he proj ect at any st age if unsat isfact ory result s seem likely. For exam ple, let 's assum e t hat an invest or has asked a soft ware com pany t o develop a port able, handheld, m edical art ificial int elligence unit t hat can perform aut om at ed m edical diagnosis for bot h

hum an and anim al life form s in real- t im e. The proj ect m anager, during t he est im at ion process, would ident ify t his proj ect as a pure R&D proj ect , and because of t he undeveloped t echnology and applicat ions required, would recom m end t hat t his proj ect be est im at ed on a phase- by- phase basis. Accuracy of Est im at ion Because accuracy is so im port ant when planning a good proj ect , I norm ally use bot h t he t op- down and bot t om - up est im at ing t echniques t o evaluat e t he result s I have achieved. I f t he result s are sim ilar, t hen I know t hat I 'm on t he right t rack. I f, however, t he result s vary considerably, t hen it m eans som et hing is wrong, and I m ay need t o review t he values again. This t im e, I will solicit expert j udgm ent by using a cert ified cost account ant or seasoned proj ect m anager t o go t hrough t he est im at ion wit h m e. Est im at ing Profit Once t he proj ect m anager has det erm ined t he resources he or she will be using on t he proj ect and against which WBS t asks, it becom es necessary for t hat project m anager t o calculat e t he selling rat e for each resource being used on t he proj ect . I t is logical t o assum e t hat t he proj ect m anager cannot sell t he resources at t he sam e price t he com pany does, and a suit able m arkup needs t o be applied against each resource t ype. Som e issues t hat need t o be considered before adding values t o any resource include t he following: •

The proj ect m anager should ensure t hat he or she has t he lat est resource rat es from t he hum an resource depart m ent or consult ant m anager ( e.g., Java developer cost s $90.00 per hour—burdened) .

•

The proj ect m anager should ensure t hat he or she has obt ained t he cost s of hardware and soft ware and has det erm ined t he com pany m arkup rat e for t hese it em s ( e.g., t he m arkup on soft ware will be 15 percent in addit ion t o t he price from which it was obt ained) .

•

The proj ect m anager should det erm ine which resources are due for salary increases, which can affect t he proj ect rat es.

•

The proj ect m anager should obt ain t he m arkup rat e or percent from t he finance depart m ent .

•

To calculat e t he gross m argin of t he proj ect , det erm ine t he difference bet ween t he selling rat e and t he direct cost t o com pany, less disbursem ent s.

The Proj ect Office Role in Est im at es I have found t hat large corporat ions and organizat ions use proj ect o ffices t o assist proj ect m anagers in ensuring t hat t heir proj ect est im at es are correct and have been reviewed before being released t o a client . Som e of t hese services are: •

Verifying and validat ing t he WBS and est im at e—tightening the est im at ion effort or identifying sloppy planning

•

Supplying t he services of a cent ral pool of cost account ant s or subj ect m at t er expert s

•

Maint aining t he hist orical dat abase of com plet ed proj ect est im at es and WBS chart s

•

Assist ing in t he present at ion or recom m ending t he proj ect est im at es for approval

Planning and Select ing Proj ect Resources I t is crit ical t o t he planning st age t hat t he proj ect m anager det erm ines exact ly what t ype of resources will be needed t o design, develop, t est , and im plem ent a specific proj ect . A vit al t ask of t he proj ect m anager is t o select t eam resources who are well- qualified t o perform t he work of t he I T proj ect . The proj ect m anager m ust ident ify t he t echnical, int erpersonal, and organizat ional skills needed t o com plet e t he proj ect . One t echnique t o det erm ine t his requirem ent is t o creat e a first - pass skills assessm ent m at rix for t he proj ect ( see Table 5.4 ) . Ta ble 5 .4 : Resource sk ills required by proj ect W BS #

Proj ect Resource

Qt y

Sk ills Required

1.2

Proj ect m anager

1

Proj ect m anagem ent , ASP, HTML, Word

2.3

Business analyst

2

Dat abase skills, Excel, Word,

3.0

Developers

3

I I S4.0, ASP, JavaScript ,

Ta ble 5 .4 : Resource sk ills required by proj ect W BS #

Proj ect Resource

Qt y

Sk ills Required HTML, PERL

4.2

Test er

1

Word, Test case developm ent

5.0

Trainer

1

Present at ion skills, PowerPoint , CBT

The proj ect m anager is t he focal point of cont act in ident ifying t he necessary skill levels. The following st eps can help proj ect m anagers det erm ine t he resources needed on t he proj ect : •

Ensure t he proj ect WBS is approved and t hat all t asks are in order and correct ly ident ified.

•

Assess each WBS act ivit y by t he core skillset s needed ( i.e., analyst s, developers, t est ers) .

•

Assess t he quant it y resources t hat would be needed per WBS act ivit y t o short en t he durat ion.

•

Docum ent each resource skillset wit h est im at ed quant it ies needed.

Planning involves underst anding how t he com pany's hum an resource policies and guidelines will affect t he proj ect . All proj ect st akeholders m ust know and underst and t heir roles in t he proj ect , which all cont ribut e t o t he success of t he proj ect . When dealing wit h any part - t im e or t em porary resources on t he proj ect , proj ect m anagers should be aware t hat t he proj ect gains t he m axim um value from part - t im e individuals assigned t o t he proj ect . So very oft en, part - t im e m em bers are recalled back t o t heir previous proj ect s on urgent m at t ers, and never ret urn. This leads t o frust rat ion, as t hese recalled resources are now unable t o work t he t im e t hat has been dedicat ed t o t he pr oject . I n order t o do t he resource planning on t he proj ect , it is necessary t o have som e base inform at ion t o get good result s. Possible sources for t his inform at ion are •

Hist orical inform at ion from a sim ilar proj ect

•

Knowledge from wit hin t he organizat ion

•

Benchm ark inform at ion from ot her organizat ions

Table 5.5 illust rat es a resource usage t echnique t hat allows t he proj ect m anager t o det erm ine t he num ber of resources t hat are required and helps t he proj ect m anager underst and t he im port ance of t he individual financial im pact s on t he proj ect . Ta ble 5 .5 : Planning for resource usage Resource Type

Qt y

Part - t im e / Cont ract or

Ra t e

Required Hours

Cost ( $ )

Proj ect m anager

1

？ ？ ？ ？ ？ ？ ？ ？

$120

160

$19,200.00

Business analyst

2

？ ？ ？ ？ ？ ？ ？ ？

$90

60

$10,800.00

Developers 3

？ ？ ？ ？ ？ ？ ？ ？

$110

250

$82,500.00

Test er

1

？ ？ ？ ？ ？ ？ ？ ？

$80

40

$3,200.00

Trainer

1

？ ？ ？ ？ ？ ？ ？ ？

36

$2,520.00

Tot al Cost

8

3

$70 ?/ t d>

546 hrs

$118,220.00

Linear Responsibilit y Ch a r t ( LRC) So m any t im es, proj ect m anagers are unsure of which resources t o assign t o which WBS t ask, result ing in com m unicat ion and coordinat ion problem s bet ween proj ect st akeholders. A useful t echnique t o aid t he proj ect m anager is t he linear responsibilit y chart ( LRC) or m at rix. I t basically com bines t he WBS against t he t ypes of resources available. This is ext rem ely useful for t he proj ect m anager, as it visually depict s who is responsible for each proj ect t ask. The following are suggest ed st eps t o fo llow when creat ing a LRC: 1. Docum ent t he proj ect WBS in a linear m anner on t he left - hand

side of t he m at rix. 2. Arrange all t he resource elem ent s from t he corporat ion

horizont ally across t he t op of t he m at rix. 3. Assess each int ersect ion point on t he m at rix t o in dicat e each

resources int erest in t he respect ive WBS act ivit ies. Had Colum bus paid closer at t ent ion t o t he works of t he ancient Greeks, he m ight have not iced t he reference t o a landm ass ext ending from nort h t o sout h in t he At lant ic Ocean, bet ween Europe and Asia. He m ight also have consult ed wit h Basque fisherm en, who were already harvest ing

schools of cod off t he coast of Labrador. Acquiring knowledge—on proj ect s—m ay j ust be a m at t er of knowing where t o find it . Valuable lessons like t hese oft en highlight t he im port ance of recognizing t he t ask at hand and put t hings int o perspect ive. Proj ect Budget The det ailed proj ect budget , which t he proj ect m anager forwards t o t he client , is final and should be t he benchm ark from which all cost s are t racked and coordinat ed. This value form s t he basis against which t he proj ect m anager should m easure t he planned versus act ual cost s. Many client s will fund proj ect s basing t hem on t heir financial calendar year. Therefore, proj ect s eit her have t o be com plet ed wit hin t hat year, or t he budget split int o t wo separat e financial years t o address t he client 's financial com m it m ent . The proj ect m anager needs t o be well versed in t he client 's budget ary process, in order t o gain underst anding of how t o subm it invoicing or generat e credit not es, if needed. The final budget is derived from t he m ost recent est im at e approved by t he proj ect m anager and t he relevant senior st akeholders. Once verified and approved, t he budget is forwarded t o t he client for proj ect approval. I t would be very unprofessional t o inform t he client t hat t he budget was not realist ic and st ill needed fine- t uning. Rem em ber t hat a good proj ect m anager will only com m it t o a schedule or budget if he or she knows it can be m et . Table 5.6 shows an exam ple of a proj ect and m ont hly budget . Ta ble 5 .6 : Proj ect budget and m ont hly budget ( $ ) Proj ect Value July August Sept em ber W BS

Oct ober

A

$19,200.00

$4,000.00

$7,200.00

B

$10,800.00

C

$82,500.00

$60,000.00

$22,500.00

D

$3,200.00

$3,200.00

E Tot al Budget

$2,520.00

$2,520.00

$4,000.00

$118,220.00 $4,000.00

$4,000.00 $10,800.00

$14,800.00 $64,000.00

$35,420.00

PROJECT COSTI N G M ODELS I t is essent ial t hat proj ect m anagers underst and t he im port ance of t he t ypes of financial cont ract s a client could im pose on t he proj ect or ones t hat t he proj ect m anager could recom m end t o t he client . Wit hout a doubt , if t he proj ect m anager is responsible for t he financial success of t he proj ect , he or she needs t o underst and how t hese cont ract s work. To

m ove ahead wit hout com prehending t he cont ract will, undoubt edly, affect t he financial aspect of t his proj ect and it will m ost cert ainly fail. Most proj ect s are form ally agreed upon and execut ed by m eans of a cont ract . I f a proj ect does not proceed according t o plan, t he client oft en has several choices: ( 1) recover what t hey can from t he proj ect and never do business wit h t he consult ing com pany again, ( 2) request t he proj ect be delivered as agreed, or ( 3) cont inue wit h legal proceedings. Cert ain financial cont ract s could negat ively affect t he planned proj ect profit s, which would result in a proj ect com ing in at a loss t o t he com pany. There are also som e financial cont ract s t hat could be beneficial if proj ect perform ance is achieved. This sect ion describes t he risks associat ed wit h each of t he m aj or t ypes of financial cont ract s t hat I have oft en seen used on I T proj ect s. Basically t here are t wo m ain cont ract m odels t o co nsider; firm fixed price ( FFP) and cost plus ( CP) ( also m ore com m only known as a t im e and m at erials cont ract ) . The CP m odel has a few variat ions t hat are applied depending on client negot iat ions, but all have been used. I shall not go int o great det ail abo ut all t he t ypes of cont ract s t hat are available for a proj ect m anager t o consider and underst and, but I will highlight t hose t hat I believe are useful ( see Figure 5.9 ) .

Figure 5 .9 : Costing m odels Firm Fix e d- Price Cont ra ct s This t ype of cont ract favors t he proj ect m anager and t he solut ion provider, even t hough t he risk is placed on t he solut ion provider t o deliver against what was quot ed. This risk works well if t he proj ect m anager has a superior knowledge of t he solut ion t ype being undert aken. I f t he proj ect

m anager cannot deliver t he solut ion as quot ed, t hen t he solut ion provider, not t he client , accom m odat es t he risk. For exam ple, let 's assum e t he client approves a quot e of $126K for a proj ect . However, at proj ect com plet ion t he cost s exceed t he $150K m ark, and t he proj ect m anager m ust explain why such a loss occurred. The client will not pay t he difference, as t hey only agreed t o t he $126K quot e. However, if t he proj ect is m anaged successfully and can achieve t he required gross m argin ( profit m argin) , t he solut ion provider will be ext rem ely sat isfied and it oft en happens t hat proj ect m anagers get suit ably com pensat ed for achieving t hese financial m argins. Tim e- and- M at erials Cont ract s A t im e- and- m aterials cont ract places t he risk wit h t he client . This t ype of cont ract is oft en used when t he cont ract or or proj ect m anager is unsure of quot ing an FFP, as t he solut ion m ay be ( 1) t oo com plex, ( 2) at a client 's request , or ( 3) used in order t o supplem ent proj ect st aff on a pr oj ect . This form of cont ract is usually adm inist ered when proj ect m anagers subm it t heir invoices t o t he client t o receive paym ent for work - hours and physical m at erials used on t he proj ect ( e.g., st at ionary, hot el st ays, and other related co st s) . These cont ract s do consum e larger port ions of adm inist rat ive burden for bot h t he client and cont ract or. For t he cont ract or, t he gross m argins do, in som e inst ances, t end t o be lower. I n t hese cases t he com m on t act ic is t o negot iat e wit h t he client t o keep t he resources for longer durat ion, which obviously is m ore beneficial t o t he cont ract or. PROJECT DOCUM EN TATI ON I t is im port ant t hat t he proj ect have sufficient docum ent at ion t o cover all relevant areas t hat would likely cause a risk or issue. This next sect ion describes som e plans t hat are im port ant t o t he success of any proj ect . Proj ect M anagem ent Plan As a proj ect m anager, I have seen plans of every size—from t wo- page proj ect plans all t he way t o docum ent s t he size of t elephone direct ories. Som e are lit erally so com plex t hat very few people act ually underst and t hem . I n effect , t he proj ect m anagem ent plan ( PMP) , also known as t he proj ect definit ion report ( PDR) , is not hing m ore t han docum ent s describing t he proj ect t hat is being undert aken. I t focuses on t he approach t o be t aken, t he t im e, cost , resources, risks, and assum pt ions ( see Figure 5.10) .

Figur e 5 .1 0 : Proj ect plan cont ent s An effect ive proj ect plan is of great help t o t he proj ect m anager because it allows individuals wit hin t he t eam t o t ake m ore responsibilit y for keeping t o t he schedule. For inst ance, a developer who will not finish a t ask on t he dat e planned is m ore likely t o let t he proj ect m anager know if he or she can see how t his wil l affect t he schedule. The plan also allows everyone t o have som e input . For exam ple, it allows a qualit y m anager t o det erm ine when t o schedule, and possibly begin t est ing earlier t han expect ed. Because of t hese t hings, a wellcom m unicat ed plan gives senior m anagem ent confidence t hat t he t eam as a whole knows what it is doing and can work t oget her t o bring about t he proj ect 's success. The approved proj ect plan is a form al docum ent used t o guide bot h proj ect execut ion and proj ect cont rol ( see Table 5.7 ) . Ta ble 5 .7 : Proj ect plan cont ent Proj ect Plan I t em s Described Cont ent in Cont ent

Techniques t o Be Use d

Tim e

Schedules

GANTT, PERT,

Cost

Budget s

Top- down, Bot t om - down

Ta ble 5 .7 : Proj ect plan cont ent Proj ect Plan Cont ent

I t em s Described in Cont ent

Techniques t o Be Use d

Resources

Availabilit y of st aff

Resource hist ogram Resource loading chart

Required proj ect phases

Various proj ect phases needed

Assessm ent

Com m unicat ion

Proj ect com m unicat ion

Roles & responsibilit ies

Risk

Technical, financial

Risk m odeling t ools

Adm inist rat ion

Proj ect support , m eetings

Organizat ional chart s

Contingency plans

Backup, disast er & recovery

Assessm ent of solut ion

By t his point t he proj ect m anager should be aware of t he level of det ail t hat he or she is going t o present in t he proj ect plan. There are different ways of addressing t he proj ect plan, depending on whet her t he proj ect is a sm all one or a super one. Table 5.8 present s key differences. Ta ble 5 .8 : Proj ect plan approach Sm all Proj ect s

Medium t o Super Proj ect s

Milest one plan for ent ire proj ect

Milest one plan for ent ire proj ect

Single act ivit y plan for proj ect ?/ t d>

Act ivit y plan for each phase Separat e plans for risk, qualit y, cont ingency, et c.

Cont ingency Plan The cont ingency plan out lines and list s t he business cont inuit y in t he unlikely event t hat t he I T proj ect fails or disrupt s t he client business area or areas. A failure can be a net work failure, applicat ion failure, syst em failure, or a com plet e and ut t er shut down of t he business. The cont ingency plan is basically developed from t he out com e of a risk analysis. All t he proj ect risks are ident ified, assessed, and cat egorized accordingly by priorit ies.

The proj ect m anager develops t he cont ingency plan for t he proj ect , including a m it igat ion st rat egy for each risk t hat is ident ified. The m ost severe or highest priorit y risks are t hose it em s likely cause a m aj or disrupt ion t o t he business wit hin a predet erm ined period of t im e ( e.g., 3 hours) . Nevert heless, because of t he pot ent ial disrupt ion t o t he business, it is vit al t o put a cont ingency plan in place, bot h during t he proj ect and also once t he syst em has been com m issioned and put in operat ion. The plan should list t he crit ical it em s likely t o fail and list t he available resources needed t o support t hese it em s. The cont ingency plan should list t he procedures t hat would be necessary t o perm it t he t im ely rest orat ion of services back to norm al. The proj ect support st aff and t est ing t eam s need t o be involved in t he cont ingency planning and need t o prepare it em s such as •

A disast er not ificat ion process and st rat egy

•

Disast er recovery and backup procedures for applicat ions and files

•

A list of who t he role players are in t he event of an em ergency

•

A list of essent ial equipm ent needed t o support t he solut ion

•

The proj ect m anager needs t o be cert ain t hat a design t o accom m odat e possible m inor disrupt ions and an alt ernat ive backup for any m aj o r disrupt ion t hat could occur are in place.

Procurem ent Plan The procurem ent plan describes t he funct ions and act ivit ies t hat are necessary t o successfully procure m at erials and equipm ent essent ial t o proj ect deploym ent . The proj ect m anager should est ablish procurem ent requirem ent s t o det erm ine which resources should be procured ext ernally versus int ernally. The procurem ent plan can be short and consist of only a few pages if required, but it should clearly list t he int ended resources needed t o im plem ent t he solut ion. These resources could be hardware, soft ware, leasing agreem ent s, licensing or any ot her m at erials required on t he proj ect . The plan specifies vendor select ion, accept ance of vendor deliverables, and t he procurem ent process policy and procedures t hat need t o be followed. Com m unicat ion Plan An effect ive com m unicat ion m anagem ent plan is crit ical t o t he success of a deploym ent proj ect , as t he proj ect m anager needs t o m aint ain a close relat ionship wit h all part ies during t he proj ect . The plan provides all

proj ect st akeholders wit h inform at ion regarding how resources are being used t o accom plish t he proj ect obj ect ives, and it serves as an effect ive t ool wit h which t o docum ent t he proj ect owner's expect at ions. The inform at ion can be post ed on a web sit e, which allows users on t he proj ect t o review im port ant docum ent at ion, schedules, and procedures. The following should be included wit hin t he proj ect com m unicat ion plan: •

All int ernal and ext ernal st akeholders who are expect ed t o support t he proj ect

•

A com m unicat ions m at rix wit h roles and responsibilit ies

•

Guidelines for all inform at ion creat ed and dist ribut ed

•

Descript ion of t he proj ect direct ory and filing syst em wit h access privileges

•

Report ing guidelines and t ypes of report s t o be used

•

Proj ect st at us m eet ings and frequency of m eet ings

•

Managem ent reviews ( design, budget , closure)

Test a nd Qua lit y Pla n Qualit y m anagem ent is necessary t o ensure t hat t he proj ect will sat isfy t he needs for which it was undert aken and exceed cust om er expect at ions. I t describes how t he proj ect t eam should im plem ent it s qualit y policy and helps guarant ee t hat all proj ect t eam m em bers underst and t hat everyone is a part ner in qualit y. An audit should be perform ed periodically t o verify t hat processes and procedures are in com pliance and t hat t he necessary qualit y review m eet ings are est ablished t o review and m ake correct ive adj ust m ent s t o t he proj ect . Checklist s should be developed t o ensure t hat proj ect plans are com plet e and t o elim inat e t he om ission of it em s. Report s relevant t o the qualit y m anagem ent of t he proj ect should be creat ed and dist ribut ed t o all proj ect st akeholders describing t he following areas: •

Qualit y obj ect ives wit hin t he scope of t he proj ect

•

Qualit y m anagem ent organizat ion, roles, and responsibilit ies

•

Docum ent at ion requirem ent s

•

Qualit y cont rol procedures

•

Applicable st andards

•

Tools, t echniques, and m et hodologies t o be em ployed

The t est ing m anager should develop t he t est plan, and it should cover all ant icipat ed t est ing act ivit ies. These act ivit ies should be synchroniz ed wit h t he overall high- level proj ect schedule. The resources should be ident ified and correct ly m at ched t o t he relevant t asks. This plan is beneficial for t he proj ect m anager, who should be able t o ident ify t he needed t est ing t asks and have a good underst anding of t he t est ing process. The t est ing plan should be developed for each proj ect phase and should consist of t he m inim um : •

Proj ect obj ect ive

•

Obj ect ive of t est s being addressed in t his st rat egy

•

Test procedures

•

Test configurat ion

•

Test resources

•

Test schedule

Developm ent Plan The t echnical st aff in t he organizat ion or on t he proj ect creat es t he developm ent plan. I n essence, t he plan present s not only what t he "change" will look like but also how t o develop t he solut ion in m ore det ail. I n m any environm ent s, t he developm ent plan has t wo m ain point s. The first focuses m ore on developm ent m et hods and approaches, including t est ing, while t he second point focuses on t he broader aspect s of adm inist rat ion and cont rol. The developm ent plan provides a disciplined approach t o organizing and m anaging t he I T proj ect . A successful I T developm ent plan would include •

Scope of t he developm ent t o be undert aken

•

An overview of t he current syst em or inform at ion syst em s environm ent

•

Benchm arking ot her processes or syst em s

•

The pro posed developm ent environm ent and int erfaces

•

Securit y considerat ions

•

Developm ent guidelines and st andards t hat will be used

•

Developm ent resources required on t he proj ect

•

Est im at ed schedule for t he developm ent

•

Change cont rol

By com plet ing t he developm ent plan early in t he planning phase of t he proj ect life cycle, t he proj ect m anager, wit h t he aid of t he developm ent m anager/ t echnical lead, can becom e fam iliar wit h t he essent ial st eps of organizing t he developm ent effort for t he proj ect . 7. Est im at e resources. 8. Est ablish schedules. 9. Assem ble st aff. 10. Set m ilest ones.

The developm ent plan should concent rat e on inform at ion t hat is unique or t ailored t o developm ent act ivit ies. I f st andard policies, guidelines, or procedures will be applied t o an aspect of t he proj ect , t he plan should reference t he docum ent s in which t hese are defined rat her t han rest at ing t hem in det ail. Writ ing of t he plan can begin as soon as any inform at ion about t he PDR and scope becom es available. The proj ect m anager should com plet e t he plan by t he end of t he init iat ion phase. I f it em s in t he developm ent plan are m issing for any reason, t he t echnical lead/ developm ent m anager should indicat e who will supply t he out st anding inform at ion and when it will be supplied. Copies of t he approved developm ent plan should be dist ribut ed t o all t echnical t eam m em bers and ident ified st akeholders. Two of t he m ost crit ical resources are developm ent resources and t im e. The developm ent m anager is concerned wit h how m uch t im e will be required t o com plet e t he proj ect and w hat st affing level will be necessary over t he developm ent cycle. The t echnical lead/ developm ent m anager usually perform s bot h st aff and t im e est im at ions, and accordingly arranges a proj ect m eet ing wit h t he proj ect m anager in order t o review t he schedule and resource requirem ent s. I ssues of st aff size and com posit ion over t he life cycle are also considered. I f t he proj ect is relat ively st raight forward and has a short proj ect life cycle, m any I T proj ect s sim ply com bine t he developm ent plan and im plem ent at ion plan. The reason is t hat m any of t he resources rem ain t he sam e t hroughout t he proj ect , m aking t he approach easier. I n such a case, a com bined plan works well. However, in t he event t hat t he proj ect is a m edium or large one, it is recom m ended t hat t he developm ent plan and t he im plem ent at ion plan be separat ed, as t he developm ent phase will m ost likely have m any changes during t he design and developm ent , which im pact s t he im plem ent at ion.

PROJECT I N FRASTRUCTURE When planning a proj ect , t he proj ect m anager could face t he possibilit y t hat t he client m ay not have sufficient infrast ruct ure t o accom m odat e t he ent ire proj ect t eam for t he proj ect . I n such an event , an opt ion t o lease m ay be t he best approach. The proj ect m anager cannot assum e t hat t he client will be providing t he necessary infrast ruct ure, and he or she needs t o clarify t his assum pt ion. I f t he infrast ruct ure is not negot iat ed wit h t he client , and no provision is m ade wit hin t he accept ed proj ect budget , it is m ore t han likely t hat t his would affect profit st art ing at day one. There are norm ally a few scenarios t hat t he proj ect m anager is likely t o encount er. However, it is very im port ant t o rem em ber t hat t here are always a few opt ions available, and t he proj ect m anager should be aware of t he im port ance and cost s associat ed wit h each opt ion. These opt ions are •

Virt ual m anagem ent ( int ernat ional or nat ional)

•

On- sit e m anagem ent ( at t he client prem ises)

•

Off- sit e m anagem ent ( at an independent or com m on facilit y used by t he cont ract or)

•

Offshore m anagem ent ( proj ect m anaged t ot ally offshore in anot her count ry)

Seasoned proj ect m anagers know t hat t rying t o im plem ent a syst em wit hout t he necessary workst at ions, hardware, and com m ercial soft ware could be disast rous t o any proj ect . Effect ive logist ics support needs t o be arranged and included int o t he overall planning phase of t he proj ect . Many proj ect s have failed because t he logist ics were not planned for or were sim ply overlooked. Lead t im es of hardware and soft ware are vit al t o t he proj ect schedule, and it is not uncom m on for essent ial it em s t o be delivered in m ont hs inst ead of t he est im at ed few days. The slippage on t he proj ect has a huge effect on t he ent ire proj ect , and t he person account able for prevent ing slippage is t he proj ect m anager. Needless t o say, t o keep t hings running sm oot hly, t he proj ect m anager needs t o be sure of several t hings. •

The hardware has been specified correct ly and been docum ent ed.

•

The delivery dat es are confirm ed and guarant eed.

•

The necessary purchase orders have been com plet ed and subm it t ed for approval int ernally.

•

The orders have been processed and placed wit h t he supplier( s) .

•

The supplier( s) has given t he delivery schedule.

•

The assem bly dat e and t he configurat ion set up of t he ordered it em s are defined.

•

The com m issioning dat es for t he ordered it em s have been confirm ed.

On- sit e Proj ect s Working on an on- sit e proj ect im plies t hat t he proj ect m anager has t o arrange for office space, logist ics, and t ravel arrangem ent s: This includes such it em s as parking, ent ry perm it s, and workst at ions. Very o ft en, t he client does not have sufficient infrast ruct ure t o fully support a proj ect and expect s t he appoint ed proj ect m anager t o arrange and finalize t hese m at t ers. I n t his case t he proj ect m anager will need t o finalize t hese arrangem ent s as quickly as possible and will need t o com m unicat e t hese requirem ent s in advance t o t he adm inist rat ion m anager at t his sit e. Off- sit e Proj ect s For t hose proj ect s t hat cannot be accom m odat ed at t he client facilit y due t o unavailabilit y of t he necessary working environm ent , it is recom m ended t hat t he proj ect m anager ensure t hat t he cont ract or is able t o provide t he infrast ruct ure needed. At t im es, t his m ay be st rat egically beneficial for t he cont ract or t o perform t he proj ect at it s sit e. Offshore Proj ect s Due t o cost effect iveness it becom es m ore feasible t o m anage and develop a proj ect offshore at an offshore cont ract or facilit y. Due t o t he high availabilit y and nat ure of t elecom m unicat ions and e- com m erce, it becom es feasible t o have proj ect s m anaged com plet ely offshore. Many organizat ions t oday out source ( 1) enhancem ent s t o exist ing I T syst em s, ( 2) com plet e proj ect design and developm ent , or ( 3) com plet e m aint enance and support t o offshore facilit ies because of t he unavailabilit y of high- t ech resources locally. I ssues such as t im e zones and t echnological barriers becom e irrelevant if t hey are m anaged correct ly. One j ust has t o look at recent exam ples of U.S. organizat ions ut ilizing t he I T infrast ruct ures est ablished in count ries such as I ndia and t he Philippines.

Est ablishing t he Proj ect I nfra st ruct ure I t is im port ant t hat t he proj ect m anager plans and set s up t he necessary infrast ruct ure prior t o any proj ect t eam m em bers st art ing on t he proj ect . Each respect ive t eam m em ber should have t he following it em s est ablished on or before t he first week of st art ing on t he proj ect : •

Physical access t o t he building ( eit her t em porary or perm anent ) . This could be in t he form of ( 1) elevat or key; ( 2) cardkey, ( 3) front door key or ( 4) scan ent ry access.

•

Em ployee num bers in hand and em ployees are on payroll

•

A desk and t elephonic inst rum ent

•

Access t o t he corporat e net work

•

Appropriat e workst at ions and required soft ware applicat ions t o perform work

•

Access t o necessary t raining in corporat e policies and cult ure

•

A m ent or t o coach t hese new m em bers on t he proj ect

•

The st andard benefit s of being on t hat proj ect , such as parking perm it s and corporat e discount s

TH E TECH N I CAL D ESI GN The t echnical phase or st age of t he proj ect is one t hat involves m any resources and consum es m any hours of careful design a nd verificat ion. Wit hout a sound t echnical design, you do not have a working syst em . I t 's t hat clear! A proj ect m anager would not want t o face a sit uat ion where only cert ain deliverables were m et , but t he proj ect failed due t o t echnological problem s t hat were not t aken int o considerat ion during t he design phase. I hope t o present proj ect m anagers wit h a good idea of what crucial elem ent s t hey should be looking for when designing t he solut ion ( see Figure 5.11) .

Figur e 5 .1 1 : The t echnical approach The design phase aim s t o ( 1) out line t he solut ion t echnically, and ( 2) consider t he required resources needed t o develop and im plem ent t he proposed syst em for t he proj ect . The proj ect m anager m ust ensure t hat t here is const ant discussion bet ween t he developm ent m anager and his or her t echnical t eam regarding t he design of t he solut ion in order t o consider t he following: ( see Table 5.9) . Ta ble 5 .9 : Design t echniques used in t he design phase Technique W ha t I t Represent s Dat a flow m odel / Diagram

Flow of dat a for t he solut ion

Ent it y relat ionship diagram (ERD)

Relat ionship m odel

Screen designs / User int erface m odel

Look and feel of solut ion

Menu net work / Screen navigat ion

Flow of t he syst em

Applicat ion prot ot ype

An explorat ory m odel of t he solut ion

Syst em int erfaces m odel

Definit ion of all t he int erfaces needed

Data dictionary

Definit ion of dat a elem ent s in dat abase

Report layout s

Definit ion of what t he required report s are

Developing t he Design Specifica t ion The proj ect m anager or developm ent m anager should prepare t he t echnical specificat ion docum ent . One of t he m ost im port ant m andat ory st eps t hat t he proj ect m anager should t ake ensuring t he proper

com plet ion of t he design specificat ion, in order t hat t he t echnical t eam s will be able t o underst and t he sequence and descript ion of t he t echnical t asks. Developers are expect ed t o code t heir pro gram s based upon t his t echnical specificat ion, and if it is incom plet e, t he developm ent will cert ainly be behind schedule and over budget . The t echnical specificat ion should m eet following requirem ent s: •

The client has t o approve t he t echnical specificat io n, as it clarifies t he client 's requirem ent s in t echnical t erm s. Addit ionally, it is used t o t est t he program s against t he approved specificat ion.

•

The t echnical specificat ion should show all t he screen layout s. This helps developers underst and t he required screen designs and it speeds up t he developm ent t im e.

•

The t echnical specificat ion should explain t he funct ionalit y of each and every obj ect / com ponent on t he required screen layout s.

•

The t echnical specificat ion should clearly indicat e t he required back- end t echnologies. For exam ple, if a screen involves any dat abase act ivit ies t hen it is good pract ice t o show all t he dat abase t ables and t he appropriat e act ions for t hose t ables by different obj ect s on t he screen. The rat ionale is t hat it aids in proper dat abase design and helps t he dat abase adm inist rat or ( DBA) t o est ablish t he necessary privileges on t he dat abase t ables.

•

The t echnical specificat ion should also st ipulat e any screens t hat involve user input , as t hese need t o be validat ed. This will help the developer t o underst and and code t he validat ions in program .

Wit hin t he t echnical specificat ion, t he developm ent m anager, t oget her wit h t he SMEs, should est im at e t he t ot al developm ent t im e needed for t he proj ect , including t im e t o t est t he solut ion. This will help t he proj ect m anager t o verify and adj ust t he init ial t im e and cost est im at e t hat was m ade.

The archit ect ural design should be concept ualized and docum ent ed in order t o represent t he high- level design of t he syst em . The design should address m aj or com ponent s and syst em int egrat ion. Design Considerat ions The proj ect m anager m ust rem ain involved wit h t he t echnical t eam during t he design of t he ent ire solut ion. Table 5.10 present s several elem ent s t hat need t o be addressed during t he design phase. Ta ble 5 .1 0 : Technical specificat ion cont ent Technical Design Crit eria

W hat Det erm ines t he Solut ion

Hardware specificat ions

Capacit y

Applicat ion soft ware specificat ions

Hardware

Dat abase schem a specificat ions

Overall archit ect ural design

Telecom m unicat ions specificat ions

Com m unicat ion

Peripheral devices

Perform ance

Applicat ion configurat ion

Operat ion & support

I nt erfaces

I m plem ent at ion

Securit y & encrypt ion

Securit y and I nt egrat ion

The proj ect m anager needs t o walk away wit h an underst anding of som e key inform at ion, once t he t echnical t eam has finalized t heir design. The proj ect m anager m ust be sure t hat •

The necessary resources have been ident ified per skillset

•

The developm ent t eam by t he I T depart m ent can accom m odat e t he expect ed st art dat e

•

He or she clearly underst ands t he cost im plicat ions, if ext ernal cont ract ors are needed t o perform cert ain deliverables. This m ay im ply t hat t he pro j ect m anager obt ains separat e cost and t im e est im at es from t hese cont ract ors.

I t does happen t hat , at t im es, proj ect m anagers are not t echnically fam iliar wit h t he respect ive t echnologies of t he proj ect , m aking t he

t echnical int eract ions and com m unicat ion wit h t he developm ent t eam difficult . However, t here are cert ain t hings t hat proj ect m anagers in t his sit uat ion can do t o work wit h a developm ent t eam . •

The proj ect m anager should address t he business logic and provide t he developers sufficient freedom for the actual developm ent .

•

The proj ect m anager should resist arguing wit h t he developers on coding t echniques. This will only frust rat e t he developers and have adverse effect on t he coding pract ices.

•

The proj ect m anager should provide t he necessary support channels t o assist t he developers wit h any t echnical difficult ies t hey m ay encount er. One m et hod is t o put t he developer( s) in t ouch wit h ot her developers who are using sim ilar t echnologies.

•

The proj ect m anager should offer t he developers opport unit ies to learn t he lat est I T skills.

Prot ot yping a Solut ion Many t im es a client cannot visualize what t he prospect ive I T syst em or product will look like unt il t he very end of t he proj ect , and t his logic leads t o changes t o t he solut ion, m aking t hings com plicat ed for all parties. I t is, however, com m on pract ice for a proj ect t eam t o develop a prot ot ype or dem onst rat ion m odel of t he I T solut ion early during t he design phase. I t m ay also be t he case t hat t he proj ect design t eam needs t o underst and t he solut ion, and insist on building a prot ot ype before com m it t ing t hem selves t o t he proj ect . Prot ot yping act ivit ies usually begin during t he ( a) requirem ent or ( b) init iat ion phase and are usually finalized by t he end of t he design phase. A prot ot ype is an early explorat ory m o del of t he soft ware solut ion t hat cont ains enough capabilit ies for use in est ablishing or refining client requirem ent s. I t even solves m any of t he developm ent problem s, and by t he t im e t he act ual developm ent begins, t he process is m uch easier t o underst and. When developing a prot ot ype m odel of t he proposed syst em , t he proj ect m anager m ust ensure t hat t he prot ot ype reflect s t he t rue environm ent in which t he solut ion will be im plem ent ed. The t echnique used t o st art t he developm ent of t he prot ot ype is called rapid applicat ion developm ent ( RAD) . Som e of t he im m ediat e benefit s of prot ot yping a solut ion for a client are

•

Higher accept ance level from t he client

•

Client involvem ent from day one, t hus im proving relat ionships

•

Rest rict ions of const ant changes downst ream (as in a convent ional proj ect )

•

The client becom es fam iliar t hrough knowledge t ransfer

I W I SH I H AD KN OW N TH AT There are several precaut ions t hat proj ect m anagers can t ake t o help m ake sure t hat t he proj ect will reach it s fullest pot ent ial. Proj ect m anagers can keep t he schedule up- t o - dat e and m ake sure it reflect s t he lat est design changes. They should be aware t hat working wit h new or unfam iliar t echnology m akes est im at ion less accurat e. They should be sure t hat t he scope of work is very clearly defined and agreed upon before doing t he work. There should be clearly defined funct ionalit y and qualit y requirem ent s, as well as agreem ent about t he cost for delivering against t hese, adj ust ing as appropriat e. I f m aj or changes t o t he proj ect are t he result of out side influences ( e.g., m arket changes) , t hen it is essent ial t o review t he business case for any change in approach. The following are som e useful t ips t hat will help proj ect m anagers det ect early warning signs t hat a proj ect is unlikely t o deliver t he bus iness benefit s. •

Users and proj ect m anagers do not know ( or do not agree on) how every part of t he solut ion will be used t o deliver business benefit s.

•

The proj ect sponsor, business m anagers, or proj ect m anager are not clear about m ut ual responsibilit y and account abilit y.

•

Plans do not include sufficient t im e t o carry out t he appropriat e business analysis of risk.

•

No plan exist s for accom m odat ing scope change or new requirem ent s.

•

The scope for t he work is incom plet e, hence scope - creep, which increases t he t im e and cost of delivering t he solut ion.

•

New funct ionalit y sim ply does not work, and t im e and cost increase as effort is expended t o m ake it work.

•

I nsufficient t im e, m oney, or resources are allocat ed t o t he pr oj ect .

Phase Com plet ion Checklist The proj ect m anager should m ake sure t hat t he following proj ect docum ent at ion is filed wit hin t he m ain proj ect folder in order t o com plet e t he proj ect planning phase: •

Proj ect definit ion report or plan

•

WBS

•

Proj ect schedule indicat ing deliverables ( GANTT chart )

•

An activ it y plan ( GANTT chart )

•

Proj ect chart er

•

Proj ect est im at e and budget

•

Technical specificat ion( s) such as billing or int erface specificat ions

•

Resource plan and ut ilizat ion chart

•

Roles and responsibilit ies

•

St at us report s

•

Minut es of t he m eet ing

•

Any inbound and o ut bound correspondence

•

All final proj ect cost s, such as t im esheet s, invoices, and so for t h

Ch a pt e r 6 : Ex e cu t in g t h e Pr oj e ct EXECUTI N G THE PROJECT The act ual execut ion of any proj ect is an excit ing t im e for all as t he execut ion phase plays an im port ant role. This is where all t he previous planning and refinem ent st art s t aking shape. This phase clearly indicat es t hat t he necessary com m it m ent has been provided t o t he proj ect in t erm s of expect at ions, t arget s, and schedule. Proj ect m anagers now need t o realize t hat high qualit y deliverables will need t o be provided from here onwards. Som et hing t hat t he proj ect m anager should be aware of right from t he very st art of t he execut ion phase of t he proj ect is t hat it is im port ant not only t o est ablish core proj ect m eet ings wit h t he m anagem ent t eam , but also t o hold frequent t echnical m eet ings wit h t he developm ent t eam t o address t he t echnical progress of t he proj ect . I f t his is not achieved, isolat ion from cert ain part ies will surely lead t o difficult ies and com m unicat ion problem s lat er on. Proj ect Plan Execut ion The proj ect m anager needs t o drive t he proj ect plan during t he proj ect execut ion phase. During t his process, t he proj ect m anager cont inually verifies t he scope of t he proj ect , m onit ors t he qualit y of deliverables, and t racks t he proj ect resources against t he proj ect m anagem ent plans t hat have been developed during t he planning phase. Developing t he Proj ect Tea m I t is im perat ive at t his st age t hat all required t eam m em bers have been assigned t o t he proj ect and t hat t hey have been briefed on t he proj ect obj ect ives. The proj ect m anager should be aware t hat part - t im e or t em porary resources on t he proj ect have a t endency t o be pulled away from t he proj ect , eit her due t o ot her com m it m ent s or higher priorit y assignm ent s. This could prove t o be difficult for t he proj ect m anager as it is highly probable t hat t he proj ect schedule will suffer and it is unlikely t hat t im e scales will be m et . The Kick - off m eet ing This is t he st age where t he proj ect m anager needs t o hold a project kickoff t he m eet ing for t he group t hat will be responsible for developing, t est ing, and support ing t he proj ect . I n som e sit uat ions t he kick-off m eet ing m ay only be held wit h t he developm ent t eam m em bers who are responsible for designing and developing t he solut ion. Sim ilarly, a separat e kick-off m eet ing is held lat er on wit h t he im plem ent at ion t eam and at t he point where t he users and client st art being involved in t he

deploym ent process. The kick-off m eet ing always t ries t o bring key m em bers of t he respect ive t eam s t oget her in order t o present t he highlevel proj ect goals and obj ect ives. The proj ect m anager also form ally int roduces all m em bers and announces t heir roles on t he proj ect during t he respect ive durat ions. Prior t o t he kick-off m eet ing, t he proj ect m anager develops a high- level proj ect schedule and plan t hat ident ifies t he high- level m ilest ones and im port ant event s. Copies of t his proj ect docum ent at ion should be dist ribut ed in order t o prepare t he expect at ions of t he t eam m em bers before t hey ent er t he kick-off m eet ing. I t is im port ant t hat t he proj ect m anager has arranged for an agenda of it em s t hat will be discussed prior t o t he act ual kick- off m eet ing. Minut es t o t his m eet ing should be docum ent ed and dist ribut ed t o at t endees, wit hin a short period of t im e, and a copy of t he m inut es should be kept in t he proj ect folder wit h all t he ot her proj ect docum ent at ion ( see Figure 6.1 ) . The obj ect ives of t he kickoff m eet ing in t he execut ion phase are •

To re- em phasize t he aim and obj ect ives of t he proj ect

•

To confirm t he scope of t he proj ect .

•

To discuss t he approach t o t he proj ect .

•

To present t he high- level proj ect plan and t he current st at us of t he proj ect

•

To discuss t he roles and responsibilit ies of each m em ber

•

To discuss t he proj ect com m unicat ion process

•

To arrange for t he next proj ect m eet ing

Figure 6 .1 : A basic proj ect agenda Delega t ing Proj ect Ta sk s Team m em bers m ust know which t ask or t asks have been assigned t o t hem and t hey m ust know when t hose t asks are t o be com plet ed. I f m em bers are unaware of t his or if t he m essages are or poorly com m unicat ed, t he proj ect t asks will end up lat e or even incorrect ly developed. The role of t he proj ect m anager is t o ensure t hat all part ies are com fort able wit h handling t heir respect ive t asks and do not appear confused. This inabilit y t o com m unicat e correct ly on a proj ect rem inds m e of a t roubled proj ect t hat I was t old t o t ake charge of. Upon calling t he first set of review m eet ings, I not iced t hat only senior m anagers of t he various int ernal depart m ent s at t ended t he m eet ings, as j unior m em bers were not required t o at t end m eet ings. The m eet ings proved t o be successful and I had felt t hat I had delegat ed t he proj ect t asks correct ly and t hat t hese t asks would be carried out . However, as som et im es happens on Fridays, I not iced som e of t he proj ect m em bers were busy wit h non- proj ect - relat ed act ivit ies, and t his concerned m e. I had clearly st ressed t he aspect of working t o m ake up t he lost t im e on t he schedule. My im m ediate discussions wit h t he proj ect developers led m e t o realize t hat t hey were unsure of t heir t asks t o be perform ed. Three days aft er I had delegat ed t he t asks, t hey were st ill wait ing for a full briefing from t heir m anagers! I

couldn't believe it . Nonet heless, I changed t he rules of all fut ure m eet ings. I st art ed t o com m unicat e wit h and delegat e direct ly t o everyone on a daily basis, and I obt ained direct feedback in t he m eet ings from each m em ber involved. My m eet ings were broken up int o t wo separat e m eet ings: •

A high- level core m eet ing where t he m anagers at t ended and t asks were delegat ed t o t hem

•

A t echnical m eet ing for t he all m em bers in order t o com m unicat e responsibilit ies and m ake sure t hat everyone knew what t o do

Every proj ect t eam m em ber should agree t hat t he schedule for his or her t asks is reasonable. Basically, each t eam m em ber knows his or her role on t he proj ect and t he ext ent of his or her aut horit y and responsibilit y. Proj ect t eam m em bers becom e t horoughly annoyed if t hey do not know what t hey are expect ed t o do or when som et hing should be finished. They are also annoyed when t hey are t old t o do som et hing t hat t hey know t hey cannot do and are not given adequat e opport unit y t o voice t heir opinion. The best advice for proj ect m anagers is t o avoid t his j ust ified annoyance. You won't regret it . Suffice it t o say, com m unicat ion is t he key t o a happy, well- run proj ect . An im port ant part of t his com m unicat ion is having a good working relat ionship wit h all t he t eam m em bers on t he pr oj ect . TH E DEVELOPM EN T BEGI N S At t his st age of t he proj ect , t he design and developm ent t eam have provided t he m ost input regarding how long it would t ake t o develop t he syst em and t he resources t hat will be required. A proj ect m anager's j ob is t o ensure t hat t he proj ect follow s t he developm ent t im e est im at es t hat were provided during t he planning phase. I t is im port ant t hat t he developm ent t eam is confident about t he act ivit ies and deliverables t hey are expect ed t o m eet . A developer m ay be confident because he or she gave t he est im at e. On t he ot her hand, a developer m ay t rust t he est im at ion t hat was given by t he t echnical lead. Eit her way, a plan works best if individuals com m it t o perform ing each t ask in t he t im efram e planned. Because proj ect m anagers have t he responsibilit y of bringing t he proj ect t o com plet ion in t he t im e specified by t he proj ect plan, it is im port ant t hat t hey have som e degree of confidence in each it em of t he plan as well. I f t hey are not confident of t he individual act ivit ies and durat ion, t here is a good chance t hat poor planning was perform ed and t hat t he proj ect was not approached correct ly.

I nvolvem ent w it h Developm ent The developm ent effort consum es a large am ount of resources and t akes t he biggest chunk out of any proj ect schedule. Wit h it com es m any changes and pot ent ial for conflict . The proj ect m anager should be act ively involved during t he developm ent , even t hough t he developers on t he t eam will be doing m ost of t he work. This does sound odd, but t he proj ect m anager needs t o keep abreast of t he progress of t hose developm ent t asks. An exam ple of poor proj ect m anager involvem ent wit h t he developm ent t eam would be where t he developers are busy creat ing an applicat ion based upon t he proj ect plan, but unbeknownst t o t he developers, addit ional changes have been int roduced t o t he design. This m ost cert ainly int errupt s t he ent ire developm ent process, as t he developers m ay have t o rest art or redouble t heir effort s t o cat ch up. The following are som e guidelines and t ips for t he proj ect m anager and developm ent t eam : •

The proj ect m anager should est ablish frequent developm ent m eet ings wit h t eam leaders and developers in order t o underst and any problem s developers are facing. This will help det erm ine necessary correct ive act ions.

•

The proj ect m anger should act ively be involved wit h t he developm ent t eam . I t is very im port ant for t he proj ect m anager t o be in t une and pace wit h t he developm ent t hat is t aking place.

•

The proj ect m anger should not change t he business logic of t he applicat ions developed by t he design and developm ent t eam . A const ant change in program logic will disrupt t he developm ent process.

•

The business requirem ent s should be provided t o t he developm ent t eam t o ensure t he correct coding of t he applicat ions.

•

The proj ect m anager should frequent ly assess t he current posit ion of t he proj ect and see if t he developm ent schedule is on t rack and if t he delivery dat es can be achieved. I f t he proj ect is behind schedule, t hen t he proj ect m anager should arrange for addit ional work - hours.

•

The proj ect m anager should fost er a knowledge t ransfer process am ong developers.

•

The proj ect m anager should m eet each developer personally and t ry t o encourage him or her t o achieve proj ect obj ect ives.

•

Team - building act ivit ies should be arranged. Taking t he t eam out for lunch m ay be a good idea.

•

Placing t oo m uch pressure on t he developers t o rush and com plet e t he physical developm ent act ivit ies will result in errors.

•

A professional relat ionship wit h t he developm ent t eam is encouraged and paves t he way for a successful proj ect developm ent . This is achieved by holding frequent com m unicat ion bet ween all part ies. I n m any cases, developers appreciat e recognit ion for creat ivit y and hard work. This recognit ion will only boost confidence and give t he ent husiasm t o work even harder.

•

I f t he proj ect dem ands t hat t he developers work addit ional hours t o m eet t he proj ect schedule, it is only fit t ing t hat t he developers receive addit ional com pensat ion for t heir work.

•

A developer's com pensat ion should be com pet it ive wit h indust ry st andards. I n t oday's m arket place developers will m ost likely leave t he proj ect if t hey are dissat isfied.

TESTI N G ON A PROJECT When it com es t o soft ware proj ect s, it is crucial t hat t est ing be perform ed at cert ain key point s of t he proj ect life cycle phases. Cert ain m ethodologies, such as t he Tim eboxing approach, allow for t he rapid prot ot yping and t est ing at each phase, whereas t he m ore t radit ional Wat erfall approach involves t est ing only aft er t he developm ent phase has been com plet ed. At t his st age, t he proj ect m anager m ust have already not ified t he t est ing t eam of t he fort hcom ing t est ing. He or she also needs t o set up a m eet ing wit h t he t est ing and qualit y assurance ( QA) st aff. At t he t est and QA m eet ing, t here will be a series of t asks and responsibilit ies t hat t he proj ect m anager has t o com m unicat e t o t he st aff. By default , t he

following t est ing st aff m em bers can be m ade available for t he t est ing phase: ( 1) t he developer, ( 2) t he business analyst , ( 3) t he syst em s analyst , ( 4) t he t est ers, and ( 5) t he end- user. The proj ect m anager m ust also ensure t hat necessary st aff has been scheduled and is available t o perform t est ing. Any unavailabilit y of resources m ust be resolved im m ediat ely prior t o t est ing beginning. Test Environm ent The proj ect m anager, t oget her wit h t he t est ing m anager, shall ensure t hat a suit able t est ing infrast ruct ure is est ablished and set up prior t o any t est ing t aking place. This could im ply separat e funding for hardware for t he proj ect , an addit ional requirem ent t hat should not be overlooked during the plannin g phase. The necessary soft ware t est t ools should also be obt ained and be available before t est ing com m ences. The t est ing resources should be t est ed in all t he necessary t est t ools before t est ing com m ences. Test ing on a proj ect is est im at ed t o cost up t o 2 5 percent of t he t ot al budget . The key t o any t est ing effort is creat ing a suit able t est environm ent in which t est ing can occur. The proj ect m anager should be fully aware t hat cert ain t est and st aging environm ent s will probably be necessary and t hat t hese will need t o be set up. These t est environm ent s involve obt aining and deploying sufficient hardware and soft ware. I f t his has not been included in t he proj ect plan, t hen it m ay be t oo lat e t o com pensat e for what m ay be a serious delay on t he overall proj ect t im e line. The t est ing of any I T proj ect needs t o be perform ed in separat e st aging environm ent s ( see Figure 6.2 ) . They are •

The developm ent environm ent ( where developm ent t akes place)

•

The t est environm ent ( where t he solut ion is t est ed)

•

A fully funct ional product ion environm ent ( t he final locat ion)

Figure 6 .2 : I T staging environm ent s Rem em ber t hat t he t est environm ent is t he first form al t est environm ent . Charact erist ics of t hat environm ent should include som e preparat ion and planning t hat are based upon t he t ype of syst em t o be t est ed. The proj ect m anager m ust inclu de t his int o t he overall planning when t he proj ect plan is being creat ed. There are several considerat ions t hat need t o be t aken int o account :

•

An appropriat e num ber of properly configured workst at ions

•

Com plet e net work connect ivit y and com m unicat ion bet ween com ponent s of t he syst em

•

The correct rout ers/ swit ches/ hubs

•

File servers

•

Sufficient disk space t o house t he applicat ion, t ools ( e.g., edit ors, debuggers, file com pares, query facilit ies) , t est dat a, and t est result s

•

Appropriat e m em ory configurat ions

•

Sim ulat ion of product ion dat abases.

•

Files/ t ables

TH E I M PORTAN CE OF TESTI N G Wit hout a well- t hought t est ing effort , t he proj ect will undoubt edly fail overall and will im pact t he ent ire operat ional perform ance of t he solut ion. Wit h a poorly t est ed solut ion, t he support and m aint enance cost will escalat e exponent ially, and t he reliabilit y of t he solut ion will be poor. Therefore, proj ect m anagers need t o realize t hat t he t est ing effort is a necessit y, not m erely as an ad hoc t ask t hat is t he last hurdle before deplo ym ent . The proj ect m anager should pay specific at t ent ion t o developing a com plet e t est ing plan and schedule. At t his st age, t he proj ect m anager should have realized t hat t his effort would have t o be accom m odat ed wit hin t he proj ect budget , as m any of t he t est ing resources will be designing, t est ing, and validat ing t he solut ion t hroughout t he ent ire proj ect life cycle—and t his consum es work - hours and resources. The t est ing effort begins at t he init ial proj ect phase ( i.e., preparing t est plans) and cont inues t hroughout unt il t he closure phase. Test ing Crit eria I t is essent ial t o conduct t est s under realist ic condit ions. I have oft en found t hat t est ers on a proj ect deliberat ely go out t o dest roy t he solut ion during t he t est ing phase in order t o do a proper t est . Som e sensible ground rules for accept ance t est ing are necessary and need t o be est ablished before any t est ing com m ences. Typically, som e of t hese rules should include t he following: •

Using real dat a and real operat ors.

•

Test t he solut ion as t he developers build it . This way, errors can be correct ed im m ediat ely.

•

I nvolve proj ect m em bers who underst and design and user specificat ions.

•

Det erm ine what is included wit hin t he t est and what is not .

•

I nvolve users of t he proj ect who know how t he syst em will be used.

•

Test t o see t hat int erfacing t he new solut ion t o t he current infrast ruct ure has no unexpect ed consequences.

•

Allow t im e for repet it ion of t hose unsat isfact ory t est result s in t he proj ect schedule.

Types of Test ing There are m any different t ypes of t est ing t hat can t ake place on an I T proj ect , and t he proj ect m anager m ust verify exact ly which t est s will be required. Table 6.1 present s t he m ost com m on t ypes of t est ing t hat I have encount ered, and I have found t hese t o work ext rem ely well. Ta ble 6 .1 : Various t ypes of proj ect t est ing Test Types

Test ed By

Approach

W hen is it Pe r for m e d

Unit testing

Developer

I nform al

Cont inuous during developm ent

I nt egrat ion t est ing

Developer / QA

Form al

Aft er unit t est ing "endt o- end"

Syst em t est ing

QA

Form al

Overall t est ing

Pilot t est ing

Developer

Form al

During Product ion

Perform ance t est ing

Sys Adm in

I nform al

Used t o t est t he speed

St ress t est ing

Developer / Ops

I nform al

Used t o t est t he load

Funct ional

QA

Form al

Aft er

Ta ble 6 .1 : Various t ypes of proj ect t est ing Test Types

Test ed By

Approach

W hen is it Pe r for m e d developm ent is com plet ed

User

Form al

Aft er release by QA t eam

t est ing User accept ance t est ing ( UAT) Unit Test ing

The prim ary purpose of a unit t est is t o provide im m ediat e verificat ion t hat t he applicat ion code perform s as specified at a st ruct ural level. Unit t est plans are less form al t han syst em s or accept ance t est plans. This form of t est ing m ay consist of using a sim ple checklist t o perform desk checking, peer reviews, and code walkt hroughs. A unit t est should exam ine 100 percent of t he processing pat hs, including edit s; it should verify program unit logic, com pilat ion accuracy, dat a handling capabilit y, int erfaces, and design ext rem es. This is a det ailed, low- level t est t hat verifies, am ong ot her t hings, t hat drop- down list s work, windows can be navigat ed correct ly, t oolbars and m enus work according t o st andards, and error m essages and help m essages work correct ly. The t eam perform s a unit t est whenever changes t o code are m ade. I n general, t he developer who coded t he unit execut es t he t est s ident ified in t he unit t est plan. I ndependent t est ers are not required unless t he unit m ust com ply wit h st ringent safet y or securit y requirem ent s. When unit t est ing is com plet e, t he developer's t eam leader or applicat ion specialist reviews t he t est result s. The reviewer cert ifies t he com plet eness and correct ness of t he t est ( i.e., result s are checked against t he t est plan t o ensure t hat all logic have been t est ed) and verifies t he accuracy of t est result s. The proj ect m anager should be inform ed of t he result s and be able t o review t his wit h t he t eam . Unit t est ing is accom plished in t he developm ent environm ent . Pilot Test ing Wit h pilot t est ing, it is necessary t hat t he new syst em be used by a lim ited num ber of product ion users in t heir norm al product ion environm ent . Users should execut e funct ions on t he new syst em , evaluat e t he result s, and assess t he im pact on perform ance reliabilit y in t heir environm ent . Before a new syst em is deployed at t he user sit e, a reim plem ent at ion pilot t est should be perform ed t o sim ulat e t he syst em in t he m anner for which it will be used. The following guidelines should help t he proj ect m anager perform reim plem ent at ion planning:

•

The proj ect m anager should choose an individual ( one who was involved in t raining and accept ance t est ing) t o be responsible for collat ing error report s and change request s.

•

This individual should be given aut horit y t o eit her aut horize or m ake im provem ent s wit hin defined lim it s.

•

A process should be est ablished t o deal wit h larger proposals for change.

•

The proj ect m anager should est ablish a m anagem ent and report ing st ruct ure t o m onit oring error report s, change request s, and report back t o t he originat ors.

•

The proj ect m anager should assess and approve all enhancem ent s and change request s on t he basis of t heir relevance and cont ribut ion t o t he business obj ect ives.

Funct ional Test ing The proj ect 's qualit y assurance t eam is responsible for looking aft er t he funct ional t est ing of t he solut ion being developed. I t is pret t y m uch front end, "click and see" t ype of t est ing. Funct ional t est ing should be designed t o ensure t hat each business specificat ion/ requirem ent has been included and works. The t est er or t est ers shall be responsible for t est planning, test do cum ent at ion, and t he validat ion. I have oft en found t hat wit hout proper t est ing st aff on t he proj ect t eam , t he proj ect encount ers problem s. I t can even get t o t he point where t he proj ect is delayed due t o inconsist encies bet ween t he specificat ions and t he syst em being t est ed. The proj ect m anager m ust be involved wit h t he t est t eam in order t o resolve any possible discrepancies t hat m ay exist . An exam ple of t his discrepancy would be if t he client int roduces changes during t he proj ect , but t hese changes were not docum ent ed correct ly by m eans of form al change request s. The purpose of funct ional t est ing is t o det ect user int erface problem s early, before developm ent is nearing final com plet ion and t he syst em is put int o product ion. Syst em Test ing A syst em s t est provides functional "end- t o - end" verificat ion t hat t he syst em perform s as a com plet e, int egrat ed product . I t 's im port ant t o m ent ion t his t ype of t est ing because m any proj ect s fail t his t est . The purpose of syst em t est ing is t o verify t he funct ionalit y of t he solution in t hat all requirem ent s and specificat ions are m et . During t his t est , t he t est t eam execut es t est s specified in t he syst em t est plans. Result s obt ained during t est execut ion are docum ent ed, and t he developm ent t eam is

not ified of any discrepancies. I n accordance wit h st ringent configurat ion m anagem ent procedures, t he developers m ust correct t he discrepancies. The syst em t eam ret est s t he correct ed soft ware, and regression t est s are execut ed t o ensure t hat previously t est ed funct ions have not been adversely affect ed. The syst em t est plan also defines t he set of regression t est s t hat will be used t o ensure t hat changes m ade t o soft ware have had no unint ended side effect s. Syst em s t est cases are built on t he prem ise t hat t he developers have com plet ed unit t est ing. Therefore, t he t est ing t eam m ay expect t hat t he code has been com piled correct ly and basic funct ionalit y is working. This inform at ion is provided t o t he proj ect m anager, who t hen prepares t he syst em for t he next st ep. Syst em t est ing begins o nce unit t est ing is com plet ed. Syst em t est s are planned and execut ed by t he t est t eam , which is a subset of t he developm ent t eam t hat includes applicat ion specialist s. The leader of t he t est t eam is responsible t o t he proj ect m anager and ensures t hat t est resources are scheduled and coordinat ed, t hat t he appropriat e t est environm ent is est ablished, and t hat ot her m em bers of t he t eam underst and t est t ools and procedures t o be used. Syst em t est ing is perform ed in a separat e cont rolled environm ent where soft ware and hardware sim ulat e a product ion environm ent . A form al configurat ion m anagem ent process is also in effect . During t est ing, t he proj ect m anager direct s t he act ions of t he t eam , ensures t hat t he t est plan is followed, responds t o unplanned event s, and devises workarounds for failures t hat t hreat en t he progress of t est ing. He or she m aint ains t est dat a and cont rol files under configurat ion m anagem ent . I nt egrat ion Test ing Final int egrat ion t est ing is very im port ant t o confirm ing t he syst em 's capabilit y. Th is phase also provides assurance t hat t he new syst em can be int egrat ed wit h t he ot her syst em s and business processes wit h which it has t o work, wit h no adverse effect s on t hem . •

A plan for doing all t he required t est s m ust be prepared, reviewed, and agreed upon j oint ly by t he purchaser ( wit h t he part icipat ion of business users of t he syst em s, I S st aff, and purchasing specialist s) and t he supplier.

•

The plan, as part of t he cont ract , should specify ( 1) t he individual who has t he responsibilit y and aut horit y for accept ance, ( 2) ot her part icipant s, ( 3) accept ance crit eria, and ( 4) t est ing procedures.

Perform a nce or St ress Test During t he life of any I T proj ect , t here are t im es when t he proj ect m anager m ust use exist ing resources ( e.g., servers, deskt op equipm ent , et c.) , prim arily due t o budget ary const raint s on purchasing new equipm ent . These resources will have a severe im pact on a proj ect if t he syst em perform ance or volum es cannot be achieved. I n order t o verify t hat t hese resources can perform as required, t he t eam conduct s perform ance, load, and st ress t est ing t o det erm ine if t here are specific problem s t hat would affect t he proj ect . Based on result s of t his t est , t weaking of t he syst em m ay be necessary. I n a worse case scenario, if t his t weaking does not work, t he proj ect m anager m ust purchase replacem ent equipm ent im m ediat ely. Accept ance Test ing The purpose of t he accept ance t est ing phase is t o dem onst rat e t hat t he syst em m eet s requirem ent s in t he operat ional environm ent . The developm ent t eam does not perform t he accept ance t est . Testing is execut ed t o see if t he proj ect m eet s t he original client requirem ent s, and it is only considered com plet e when all t est s specified in t he accept ance t est plan have been run successfully. Accept ance t est ing guarant ees com pliance with end- user requirem ent s and det erm ines whet her a syst em int egrat es int o t he operat ional environm ent . Accept ance t est ing is done aft er t he com plet ion of syst em t est ing. At t he conclusion of syst em s t est ing, t here is a m eet ing t o decide if t he applicat ion is ready for accept ance t est ing. All known crit ical defect s should be fixed and t est ed prior t o t he st art of accept ance t est ing. The goal is t o m ake no m ore changes t o t he applicat ion or environm ent once accept ance t est ing begins. During accept ance t est ing, t he I T developm ent t eam assist s t he t est t eam and m ay execut e t he accept ance t est s under t he direct ion of t he accept ance t est t eam . The developm ent t eam correct s any errors uncovered by t he t est s. Accept ance t est ing is considered com plet e when all t est s specified in t he accept ance t est plan have been run successfully and t he syst em has been form ally accept ed. The developm ent t eam t hen delivers final versions of t he soft ware and syst em docum ent at ion ( t he user guide and syst em descript ion) t o t he cust om er. The purpose of an accept ance t est is t o allow t he user t o verify t he following: •

The syst em is st able, works as an int egrat ed syst em , and is present ed t o t he users as a product .

•

Dat abases support ing t he syst em have t he scope t o cover t he business co rrect ly.

•

Dat a ent ry and report s all present dat a in a correct m anner.

•

The syst em int eract s correct ly wit h exist ing syst em s.

•

Business processes are correct ly reflect ed wit hin t he syst em and allow defined business procedures t o operat e as required.

•

Error pro cessing is handled effect ively and user help facilit ies are com plet ed and usable.

•

Syst em adm inist rat ion funct ions and syst em securit y are correct ly support ed.

•

Bat ch processing wit hin t he syst em and wit h relat ed syst em s works wit hin t he sequences and t im ings necessary t o support t he business.

•

The syst em is capable of handling m ult iple t ransact ions and of support ing concurrent users.

At t he end of accept ance t est ing, when all accept ance t est s have been com plet ed, a final report docum ent ing t est ing result s is prepared and m aint ained in t he proj ect folder. This includes a final det ailed report on each t est , in addit ion t o an overall sum m ary t hat gives an overview of t he t est ing process and records how m any t est it em s passed during each round of t est ing. Test Cases and Script s Test cases are creat ed for t he t est ing effort in order t o sim ulat e t he product s used by t he client in a t ypical day, week, and m ont h of client act ivit y. Subset s of t est cases developed for syst em t est ing m ay be used in accept ance t est ing. These t est script s should provide inform at ion and t em plat es showing how t he act ual t est cases/ script s will be docum ent ed. The t est cases/ script s docum ent t he specific input s for t he t est scenarios being used, and t heir result s are required t o det erm ine if t he t ransact ion is successful or if it result s in an error. The form at of t he t est cases/ script s should be developed t o allow for t he recording of act ual result s once t he t est has been run. For m aj or t est ing effort s, especially t hose involving t he feeding of t est dat a from one syst em t o anot her, t he progress of t est cases should be m onit ored. I n large proj ect s it is com m on t o use an aut om at ed t est m anagem ent t ool. I f an aut om at ed t ool is not available, a spreadsheet should be creat ed t o t rack t he progress of t est cases. The current st at us

on all defect s should be m ade available and be updat ed at regular t est m eet ings. PROJECT BUDGET Once t he proj ect m anager has been assigned t o t he proj ect , it is very likely he or she will learn how im port ant funding and cash flow are t o an organizat ion for t hose proj ect s t hat have approved funding. Cert ain organizat ions require t hat t he allocat ed proj ect funds be spent before t heir financial year is com plet e, as t hese funds cannot be rolled over t o t he following financial year. The rem aining organizat ions do not follow t his process and allow for financial rollovers. When working wit h t he budget , t he proj ect m anager needs t o det erm ine which plan t he com pany is using. The proj ect m anager needs t o process t he necessary equipm ent list s and resources and put t hem int o t he financial process. By t his st age, t he proj ect budget is fixed and t he proj ect 's success is m easured against t he cash flow and also m eet ing t he budget . I t 's no use having t he budget but wait ing unt il t he end t o t ry t o spend it . W orking w it h t he Budget Once in t he execut ion phase, t he proj ect budget should already form t he baseline for which all proj ect cost s are m easured. From t his point forward, it becom es ext rem ely difficult t o t urn back. The proj ect m anager should underst and t hat t he budget is fixed and t hat no addit ional funds will be allocat ed t o t he proj ect . However, m any proj ect s do not follow t his rout e, as m any organizat ions or even t heir own depart m ent s have phenom enal budget s, and can allow for t he t ransfer or re- allocat ion of funds from one account t o assist t he ailing proj ect budget . I n such environm ent s, proj ect m anagers sim ply advocat e for addit ional funding when needed. A successful proj ect m anager is inst rum ent al in m anaging t he proj ect budget at all t im es, and he or she m ust ensure t hat act ual expenses are in line wit h t he init ial est im at es and planning. As t he proj ect is being execut ed, t hose planned resource expenses such as com put er hardware or soft ware should be ordered and paid for out of t he proj ect budget , not general com pany budget s. The goal is for t he proj ect m anager t o m anage t he budget and proj ect ed cash flow alm ost as if he or she were m anaging his or her own business. Managing t he budget allows t he proj ect m anager t o be sensit ive t o overspending and exceeding cost s ( see Figure 6.3 ) . St rong fiscal discipline will pave t he way t o proj ect success. I t is com m on for m any organizat io ns t hat deliver solut ions t o award t heir proj ect m anagers lucrat ive incent ives for achieving proj ect success and repeat business from t heir client s.

Figure 6 .3 : Managing t he proj ect cash flow Ensuring Financial Support for t he Proj ect During t he life of t he proj ect , it is very likely t hat t he client 's or supplier's financial depart m ent will cont act t he proj ect m anager regarding cert ain financial m at t ers. This could be t o inquire or t o request inform at ion from t he proj ect m anager regarding •

Resource rat es and bonuses allocat ed t o proj ect st aff

•

Overt im e paym ent s

•

New resources hired on t he proj ect

•

Cash flow proj ect ions

•

Out st anding paym ent s and purchase order docum ent at ion

•

Approval of cont ract or invoices

•

I t em s t hat are over budget

•

Proj ect work in progress

I t becom es crucial for t he proj ect m anager t o underst and t he ro le of t he financial depart m ent and t he im port ance it plays as a support funct ion for t he proj ect . Som e financial support t asks could t ake considerable t im e t o expedit e and t o be put int o m ot ion, and it t herefore becom es necessary t o know t he t im e it t akes t o process. This alone will solve m any of t he proj ect m anager's frust rat ions.

PROCUREM EN T OF EQUI PM EN T AN D SERVI CES I n t oday's vast t echnological landscape, it is highly unlikely t hat one single com pany will be able t o supply it s own product s and services for an I T solut ion. Som e of t hese product s or services will have t o be obt ained from ext ernal sources, and as such, t he proj ect m anager will end up having t o m anage t he ent ire process of negot iat ing and procuring t hese resources once t he proj ect is execut ed. The proj ect m anager m ust review, negot iat e, and approve all supplier and subcont ract or proj ect delivery dat es and schedules in order t o m ap t hem against t he m ast er proj ect plan. The proj ect m anager is also t he single point of cont act for aut horizing work during t he execut ion phase. This includes conduct ing form al proj ect reviews, perform ing ongoing risk assessm ent s, and cont rolling supplier and sub- cont ract or act ivit ies. Maint aining Cont ract ual Docum ent at ion All cont ract ual docum ent at ion t hat is relat ed t o t he proj ect or solut ion should be form ally ident ified once received and be kept under form al docum ent at ion m anagem ent . Som e exam ples of cont ract ual docum ent at ion include a ( 1) client cont ract , ( 2) purchase order, ( 3) let t er of int ent , ( 4) official client correspondence, and even ( 5) m inut es of a m eet ing st at ing cont ract ual t erm s and agreem ent s. To m aint ain cont ract ual docum ent at ion, t he proj ect m anager should creat e a form al proj ect folder for all cont ract ual docum ent at ion and file papers in t he order t hat t hey are received from t he client or suppliers. This folder should be cont rolled by t he financial depart m ent , t he configurat ion and docum ent at ion depart m ent of t he com pany, or t he proj ect office. CON FI GURATI ON MAN AGEMEN T All proj ect s depend upon good configurat ion m anagem ent , and t he proj ect m anager needs t o underst and t hat change will t ake place during t he proj ect life cycle. This change needs t o be m anaged. Configurat ion m anagem ent is t he t erm applied t o where all t he proj ect inform at ion ( including source code, docum ent at ion, cont ent , and syst em s) is correct ly ident ified, cont rolled, and m aint ained for possible fut ure use. I t is advisable t hat t he proj ect m anager develops a configurat ion m anagem ent process for t racking any change request s. Configurat ion m anagem ent has four prim e areas of int erest : 1. Configurat ion ident ificat ion. This area is concerned wit h being

able t o ident ify all it em s on a proj ect t hat m ust be placed under control.

2. Configurat ion change cont rol. A process is est ablished where

t he pro j ect m anager can t rack all change request s on t he proj ect and can assess t he im pact of t hese changes t o t he proj ect schedule and resources. 3. Configurat ion account ing. This area is concerned wit h being

able t o draw t he necessary configurat ion report s on t he proj ect and account for all configurat ion it em s on t he proj ect . 4. Configurat ion audit ing. This area is concerned wit h being able

t o assess and audit t he proj ect from a configurat ion perspect ive. The out com e of t he audit will allow t he proj ect m anager t o im plem ent t he necessary correct ive act ions. M anaging Scope Creep To any seasoned proj ect m anager, t he t hought of im plem ent ing t he solut ion as designed is t he perfect scenario. However, it is likely t hat before im plem ent ing a new syst em , a flow of change requests for m odificat ions and enhancem ent s will st art pouring in from various sources. This should m ake t he proj ect m anager consider carefully t he decisions at hand. There m ay already be a backlog of changes t hat were request ed, but not incorporat ed, during t he syst em s developm ent process. I nit ially, t here will be m any request s for sm all im provem ent s and som e cust om izat ion. However, t hese will be followed by requirem ent s for m aj or changes as t he needs of t he business change. I nevit ably, as a proj ect develops, new requirem ent s and syst em capabilit ies are discovered. A well- planned proj ect should be able t o t ake advant age of t hese, but only if t he changes are j udged relevant t o t he core business obj ect ives and t hey do not increase t he risks involved in t he proj ect . I W I SH I H AD KN OW N TH AT The following are som e guidelines t o help proj ect m anagers during t he execut ion phase. •

Som e proj ect m et hodologies are not t he sam e and m ay require different developm ent processes.

•

Dat a qualit y and proj ect consist ency can be m aj or stum bling blocks in achieving success.

•

Make sure t hat all t he t ools are in place for t he st aff.

•

Monit or proj ect cost s and t im e in order t o avoid over- runs.

•

Keep proj ect m eet ings on a frequent basis and com m unicat e st at us t o all st akeholders. Oft en, proj ect m anagers get so caught up wit h proj ect issues t hat t hey neglect com m unicat ion issues, which can cause som e conflict lat er on. A proj ect m anager who does not com m unicat e effect ively could hear, "We were not inform ed as t o t he urgency t his t ask, so we left it 't ill lat er," or, "You did not t ell us we could do t hat ."

•

I f you don't have t he necessary resources and available t im e t o perform t est ing on t he proj ect , you are lost !

•

Early t est preparat ion leads t o t he resources underst anding what t o do and uncovers possible problem s.

•

Ensure t he t est ers st ress t he lim it at ions of t he solut ion.

•

Test s m ust be planned by t he t est ers and be synchronized wit h t he overall proj ect schedule.

•

Ensure t hat t he business requirem ent s and proj ect plan are updat ed t o t he st age t hat t he t est ing begins. I ncom plet e or out dat ed docum ent at ion delays t he t est ing process!

•

Review all t est ing report s. Verify and discuss wit h t he developm ent t eam t he correct ions t o be reworked and t he im pact t hey could have on t he t im eline.

Phase Com plet ion Che ck list The proj ect m anager should ensure t hat t he following proj ect docum ent at ion is filed wit hin t he m ain proj ect folder in order t o com plet e t he proj ect execut ion phase: •

Updat ed proj ect plan

•

Updat ed proj ect schedule

•

Qualit y assurance plan

•

Test plan wit h relevant t est cases

•

Contingency plan

•

St at us report s

•

Minut es of t he m eet ing

•

Any inbound and out bound correspondence

•

All final proj ect cost s, such as t im esheet s, invoices, and so for t h

Ch a pt e r 7 : Con t r ollin g t h e Pr oj e ct PROJECT CON TROL AN D MON I TORI N G I f I were t o define what t he cont rol phase of a proj ect was, I would begin by st at ing t hat t he proj ect m anager m ust cont inually m easure and cont rol all variances t hroughout all phases of a proj ect life cycle. You can equat e cont rol of a proj ect wit h t he navigat ion of a sailing boat . I t is t he capt ain's responsibilit y t hat t he vessel rem ains on it s predet erm ined plot t ed course and t hat it reaches it s final dest inat ion. Sim ilarly, t he proj ect m anager needs t o keep t he proj ect on t he course set by it s plot t ed obj ect ives. An accurat e snapshot of t he act ual proj ect ( where it is) and wit h t he planned st at us ( where it is supposed t o be) m ust be m ade at regular int ervals, as t his is t he only way t o cont rol a proj ect . The aim of proj ect cont rol, in a nut shell, is t o com pare t he act ual progress and perform ance against t he proj ect plan. The proj ect m anager t herefore has t o analyze any variances, review possible alt ernat ives, and t ake t he appropriat e correct ive act ion. Undoubt edly, proj ect m anagers need t o cont rol t heir project s on a regular basis; wit hout t his cont rol being in place, an ever- increasing level of unnecessary det ail will appear. Table 7.1 illustrat es t he key differences bet ween m onit oring and correct ive act ions. Ta ble 7 .1 : M onit oring and relat ed correct ive act ions on a project Monit oring

Correct ive Act ion

Measuring progress

Det erm ining t he correct ive act ions needed

Com paring act ual result s t o planned result s

Assessing perform ance and im provem ent

Evaluat ing gaps on t he proj ect

Updat ing changes t o t he required plans

Predict ing possible out com es and trends

Com m unicat ing and adj ust ing t ot al proj ect plan

Wit hout effect ive cont rol and prevent at ive m easures in place, t he proj ect m anager is not able t o det erm ine which m ilest ones or t asks are behind schedule, over budget , what t he issues or risks are, or even by how far t he proj ect is failing. I have found t hat t he longer a proj ect is left uncont rolled, t he m ore difficult it becom es t o ant icipat e what problem s t he proj ect will encount er. The proj ect m anager's prim e role during t his

phase is t o ( a) ident ify all sym pt om s or fact ors t hat would j eopardize t he proj ect and ( b) out line t he process for bring ing t he proj ect back on t rack. This chapt er helps proj ect m anagers underst and t hose issues and fact ors t hat t hey need t o cont rol on any proj ect . I t is m y goal t hat readers will be in full cont rol or underst and t he cont rol t echniques for t heir proj ect s by t he t im e t hey com plet e t his chapt er. Because proj ect s are large effort s t hat involve m any variables, unexpect ed t hings happen from t im e t o t im e, and t hese do affect t he proj ect . A seasoned proj ect m anager allows for m inor set backs, whereas m aj or set backs ( such as m issing a m aj or m ilest one or crit ical t ask) necessit at e t hat t he proj ect m anager t ake em ergency count erm easures and im m ediat ely work on t he issues and risks. I n som e cases, it m ay be t oo lat e and will cause t he proj ect t o fall behind schedule or exceed t he allocat ed cost s for t hat it em . To bring a proj ect on schedule and on budget , proj ect m anagers m ust know, at all t im es, how t he proj ect is progressing and what is causing any slippages. Com pany execut ives require proj ect m anagers t o be able t o cont rol t heir proj ect s and, as such, require const ant proj ect progress report s. A proj ect m anager can cont rol t he proj ect using a basic, t hree- st ep process. 1. Det erm ine proj ect st at us and if obj ect ives are being m et . 2. Com pare t he st at us against proj ect planning. 3. Assess t he cause of problem s and im plem ent correct ive act ions.

W hat t he Proj ect Manager Cont rols The proj ect m anager has t o m easure m any t hings during t he course of a proj ect , and he or she m ust t ake act ions t o guarant ee t hat cont rol ( see Figure 7.1 ) . The proj ect m anager m ust •

Measure and review t he proj ect schedule progress against t he plan

•

Measure and review t he proj ect cost progress against t he plan

•

Measure and review proj ect qualit y

•

Ant icipat e possible changes and alt ernat ives

•

Manage issues and risks

•

Cont rol scope creep t hrough a change m anagem ent process

•

Ensure t hat delivery of m ilest ones t akes place according t o client expect at ions

•

Coordinat e t he proj ect t eam

•

Monit or physical resources by cont rolling t he scheduling of resources during t he proj ect

•

Com m unicat e proj ect st at us t o t he t eam

Figure 7 .1 : Elem ent s of proj ect cont rol KEY CON TROL AREAS Cont rolling t he Proj ect Schedule There are several ways t o updat e t he schedule. The m ost frequent ly used m et hods are percent com plet ed, rem aining durat ion, durat ion com plet ed, est im at ed com plet ion dat e, and act ual st art and act ual finish dat es. The goal is t o provide enough inform at ion t o com pare accurat ely t he present proj ect st at us t o t he planned t arget .

Proj ect m anagers should always be aware t hat any delay in proj ect im plem ent at ion places t he proj ect at risk of possibly being overt aken by t echnological change. I f t his is t he case, it is vit al t hat proj ect plans are flexible enough t o allow for t he insert ion of newer t echnologies when t hey are released. Som e of t he schedule issues t hat need t o be cont rolled are •

Erroneous act ivit y sequencing ( incorrect WBS)

•

Proj ect t asks being incorrect because t he quant it ies of resources are unavailable

•

Changing requirem ents ( w hich always require addit ional rework and t im e)

• •

I ncorrect or unrealist ic act ivit y durat ion est im at es

Cont rolling Proj ect Resources The responsibilit y of m anaging t he correct quant it y of resources on a proj ect is dem anding. Proj ect m anagers m ust ensure t hat sufficient resources are used on all proj ect act ivit ies t hat were planned earlier during t he proj ect- planning phase. I n m any sit uat ions, t here are eit her t oo lit t le or t oo m any st aff m em bers perform ing t hese t asks, and it becom es t he responsibilit y of t he proj ect m anager t o level t hese resources out and t o m aint ain t he right am ount of resources on t he t ask. I t doesn't m ake any financial sense t o keep addit ional resources on t he proj ect if t hey won't be used again. So, t hese m em bers will likely have t o be released. I f t he resources have specialist skills t hat are considered crucial t o t he client , t hen t he necessary arrangem ent s m ust be m ade t o ret ain t hose resources. I f, however, proj ect m anagers find t hat t hey have t oo few resources working on an im port ant t ask t hat has t o be com plet ed wit hin a cert ain dat e, t hen t here are a few opt ions available ( see Figure 7.2 ) . •

Add addit ional st aff m em bers from ot her t asks t o t he im port ant t ask, hoping t o reduce t he durat ion.

•

Hire addit ional resources j ust for t he t ask durat ion.

Figure 7 .2 : Resource leveling Cont rolling Proj ect Cost s The proj ect m anager m ust capt ure, t rack, and cont rol all proj ect - relat ed cost s t hat are incurred against planned proj ect cost it em s. Whet her it is proj ect t im esheet s, hardware, or t ravel expenses, it is essent ial t hat all cost s be reflect ed against t he proj ect . This provides a realist ic m easure of what t he proj ect cost t he com pany at t he end of t he day. Addit ionally, it also helps m easure how well t he proj ect was planned. I t is necessary t hat t hese cost s be capt ured on t he proj ect syst em t hat t he proj ect m anager is using. I n t he event where unforeseen cost s arise, it is t he proj ect m anager's responsibilit y t o im m ediat ely com pare t he cost it em ( invoice) against t he planned proj ect cost WBS t ask. I f t here is a difference, it im plies a loss on t he specific WBS work package, not necessarily on t he t ot al proj ect . I f t he t endency is sim ilar on m any of t he WBS t asks, t hen it is probable t hat t he proj ect will be heading for a loss, indicat ing bad planning and est im at ion. There is not hing t hat t he proj ect m anager is able t o do. To aid t he proj ect m anagers in cost cont rol, t he following it em s need t o be verified: •

The budget allocat ions are accurat e and correct .

•

The original proj ect est im at e and budget are correct .

•

The original prices used t o develop t he est im at e st ill ap ply and are firm .

•

Technical difficult ies will affect t he cost of t he proj ect .

However, when cost s are incurred against t he proj ect and it is found t hat an act ual cost it em is slight ly higher t han t he planned WBS cost , t he proj ect m anager m ust ensure t hat , for t he proj ect t o rem ain profit able t o t he com pany, no m ore addit ional cost overruns can be t olerat ed. The cost s m ust now be cont rolled even m ore t han ever. Rem em ber, depending on t he cont ract value, t he overall proj ect will not im m ediat ely reflect t his loss; init ially only single WBS it em s reflect t his loss. The proj ect m anager needs t o com m unicat e t his necessary inform at ion t o t he execut ive t eam . Let 's assum e t he following proj ect scenario: As proj ect m anager you planned t he proj ect ext rem ely well, received t he purchase order from t he client , and com m enced work on a $ 4 0 0 ,0 0 0 I T proj ect . During your init ial est im at ions and planning you obt ained quot at ions from your hardware vendor for $ 6 0 ,0 0 0 . Subsequent ly, you included your com pany m arkup on t he hardware and cam e t o a WBS cost it em of $ 6 5 ,0 0 0 . However, during t he proj ect , t he vendor inform s you of m anufact urer increases, and t he vendor's new cost is now $ 6 6 ,0 0 0 . You im m ediat ely review t he WBS, and it reflect s a short fall of - $ 1 ,0 0 0 . Not only have you failed t o break even, you realize you are over budget for t his it em . You explore alt ernat ive vendors, but none exist . Accordingly, you inform t he execut ive t eam of t he cost overrun and t he decision is m ade t o carry t he cost . The proj ect m anager does not want t he proj ect t o run int o sim ilar financial losses and realizes t hat if t he rem aining proj ect cost s ( schedule and t ravel) are kept in check and even im proved, t he possibilit y exist s t o reduce t he short fall and st ill m aint ain t he profit m argin. ADDRESSI N G EARN ED VALUE I 'll be honest and st at e t hat I never form ally at t ended an earned value ( EV) course, as m ost of m y t im e was engulfed on physical proj ect s, and it t ook m e a long t im e t o underst and what t he concept of earned value was all about . I n m y search t o learn som et hing on earned value, I found out t hat being direct ly exposed t o proj ect s where I dealt wit h proj ect cost s and report ing helped m e underst and it bet t er. Sure, t here are som e basic EV form ulas t o learn, and one needs t o apply t he concept a few t im es t o get it right . However, once som eone has t he hang of it , it will put a new perspect ive on t he way t hat person looks at any proj ect in t he fut ure, and t his m akes it such an excit ing t ool t o use.

There are t hose groups t hat advocat e t hat earned value is ext rem ely com plex t o im plem ent wit hin an organizat ion and t hat it is seen as a way t o circum vent already est ablished financial processes t hat are current ly used wit hin organizat ions. But t his is not t he case: Proj ect m anagers also need t o have t he necessary t ools and abilit ies t o m onit or and report accurat ely on t heir proj ect perform ance at a m om ent 's not ice. Earned value offers t his abilit y. Sim ply put , earned value is a proj ect t echnique t hat proj ect m anagers can use t o m onit or, t rack, and report on t he perform ance of any proj ect . I t s use is not lim it ed j ust t o t he super proj ect s, as it applies equally t o bot h sm all and m edium sized proj ect s. The t echnique lends it self t o j oint ly plot t ing bot h t he proj ect schedule and cost values on an S- curve chart or t able. Once used, t he proj ect m anager can very quickly highlight posit ive or negat ive variances. The proj ect m anager cannot j ust m easure t he proj ect schedule alone and m ake t he assum pt ion t hat proj ect t asks are ahead of schedule and t hat t he proj ect is doing well. I t m ay very well be t he case t hat t he proj ect is exceeding proj ect cost s, m aking it unprofit able. This is why bot h schedule and cost have t o be m easured sim ult aneously t o gain a m ore accurat e pict ure ( see Figure 7.3 ) .

Figure 7 .3 : Cont rolling bot h proj ect schedule and cost

Cost and Schedule Variance Proj ect m anagers have t radit ionally always m easured t he act ual proj ect cost s t o t heir planned cost s as docum ent ed in t heir proj ect plans and budget s. There are a few possible variances a proj ect m anager could face. 1. Posit ive cost variance. This indicat es t hat t he proj ect m anager

is well wit hin spending and is under budget for proj ect t asks or act ivit ies. For exam ple, Task G had $6,000 planned against it , but only $4,800 was spent on t his t ask. This indicat es a posit ive variance of $1,200. 2. Negat ive cost variance. This indicat es t hat t here is a cost

overrun on t he proj ect and t hat it is over budget for specific proj ect t asks or act ivit ies. This is basically a red flag for t he proj ect m anager. For exam ple, Task D had $9,000 planned against it, but the proj ect m anager act ually spent $9,600 on t his t ask. This indicat es a negat ive variance of - $600. The previously m ent ioned cost variances, unfort unat ely, do not t ake anyt hing relat ing t o t he proj ect schedule int o account , and t hat 's our problem . We have t o rely on earned value t o supplem ent our exam ple in t erm s of schedule as well. Let 's re- exam ine t he cost variance scenarios again. Here we subt ract our act ual cost s ( act ual cost of work perform ed, or ACWP) from our earned value ( budget ed cost of work perfo rm ed, or BCWP) t o get our result s. So, if Task G had $6,000 planned against it and had act ual cost s of ACW P = $ 4 ,8 0 0 and we assum e we have earned a BCW P ca lcula t ion of = $ 5 ,0 0 0 , t hen t he cost variance ( CV) for Task G is BCW P - ACW P, which is $ 5 ,0 0 0 - $ 4 ,8 00 = $ 2 0 0 . This indicat es a posit ive cost variance of $200 and can be also seen as a cost saving of $200. Sim ilarly, let 's exam ine our ot her exam ple. Task D had $9,000 planned against it and has act ual cost s of ACW P = $ 9 ,6 0 0 . I f we assum e we have earned a BCW P calculat ion of $ 8 ,0 0 0 t hen t he CV for Task D is BCW P - ACW P, which is $ 8 ,0 0 0 - $ 9 ,6 0 0 = -$ 1 ,6 0 0 . This indicat es a negat ive cost variance of -$1,600 and can also be seen as a cost overrun on t he proj ect .

The EV t echnique obviously blows a lot of t radit ional t echniques out of t he wat er, in t hat proj ect m anagers previously only m onit ored t heir Gant t chart s or separat e cost report s generat ed from financial syst em s. Using earned value, proj ect m anagers are able t o sim ult aneously m onit or and cont rol bot h schedule and cost using t he set of form ulae shown in Table 7.2 . Ta ble 7 .2 : Earned value form ulae Earned Value

Det erm ines

Budget ed cost o f work scheduled ( BCWS)

A proj ect m anager uses BCWS t o represent t he value of work t o be budget ed.

Act ual cost of work perform ed ( ACWP)

A proj ect m anager uses ACWP t o represent t he act ual cost spent t o com plet e t he t ask.

Budget ed cost of work perform ed ( BCWP)

This is also known as earned value.

Cost variance ( CV)

This is known as t he difference bet ween t he planned and act ual cost s for t he com plet ed t asks. I t can eit her be posit ive or negat ive in value.

Cost variance percent age ( CV% )

This is expressed as a percent age. A posit ive value is good: I t m eans t he proj ect is under budget . However, a negat ive value m eans t hat t he proj ect is over budget , and t hat is cause for im m ediat e correct ion.

Est im at e at com plet ion ( EAC)

This is used t o recalculat e a proj ect budget , in order t o obt ain a m ore accurat e value of what t he proj ect will cost at t he end.

Because m any client s have t heir financial depart m ent s prepare financial report s and m onit or work in progress, eit her at a proj ect or operat ional level, t hese financial report s are generat ed eit her at quart erly or m ont hly. This is accordingly far t oo lat e t o cont rol proj ect cost s and any ident ified problem s, which, in t urn, would oft en be t o lat e for any correct ive act ion t o t ake place. The proj ect m anager, on t he other hand, cannot wait t hat long t o cont rol his or her proj ect cost s and t herefore needs t o be proact ive in m uch short er int ervals—oft en on a daily or weekly basis. I t is recom m ended t hat proj ect s be cont rolled from t he 15 percent m ark. There is no doubt t hat earned value, if properly applied, is highly effect ive in giving a m eaningful m easure of progress. And, t he principles are j ust

as valid for I T developm ent m anagers as t hey are for proj ect m anagers ( see Figure 7.4 ) .

Figure 7 .4 : Earned value form ulae The 5 0 - 5 0 and 0– 1 0 0 Rules Many proj ect m anagers t radit ionally report proj ect schedule progress by using an increm ent al est im at ion m et hod. This m et hod norm ally st art s by est im at ing t asks at levels such as 15 percent , 40 percent , 78 percent , or 98 percent , increm ent ally m oving forward unt il 100 percent com plet e. This process is based on no proper quant it at ive m easurem ent and is oft en inaccurat e. Addit ionally, t his inform at ion is, in t urn, subm it t ed t o eit her t he proj ect office or execut ives t o review, and percept ions at t he senior level are based on inaccurat e proj ect dat a.

Proj ect m anagers could possibly consider adopt ing a m ore accurat e m et hod of report ing on proj ect progress. I n t he proj ect world, t wo of t hese m et hods are t he 50 -50 and 0– 100 rules. However, in t he I T environm ent , t he 50 -50 rule is m ore com m only used. The im port ant t hing t o rem em ber is t o keep it sim ple ( see Figure 7.5 ) . Rem em ber t hat keeping t he schedule variance sim ple on t he progress report ing side m akes calculat ing t he EV easier t o m anage. The way t o im plem ent t he 5 0- 50 rule is fairly st raight forward. •

Assign 50 percent of t he BCWP t o t he t ask t he m om ent t he t ask is st art ed. At t his point it is assum ed t hat half t he work has been done already.

•

Assign 100 percent of t he BCWP t he m om ent t he t ask ends. This is only allocat ed once t he t ask act ually finishes.

Figure 7 .5 : The 50 -50 rule technique The 0 –100 rule works exact ly t he sam e way: •

Assign 0 percent t o indicat e t hat t he proj ect t ask has not yet begun.

•

Assign 50 percent t o indicat e t hat t he t ask is halfway com plet e.

•

Assign 100 percent t o indicat e t hat t he proj ect is com plet e.

Maint aining t he Cost Baseline I t is im portant to establish a proj ect baseline, as t his is necessary t o m easure t he act ual values incurred at any t im e on t he proj ect against t he planned values. Proj ect m anagers should realize t hat t hey have t o m easure t heir progress against t he baseline plan during all t he subsequent proj ect phases and t hat t he level of t racking increases exponent ially during a deploym ent proj ect . Proj ect m anagers should est ablish a review st rat egy and com m unicat ion plan t o encourage current , accurat e, and consist ent feedback. Tim e She e t s All proj ect s, in som e or anot her, ut ilize t im e sheet s as t he foundat ion for capt uring and coordinat ing work perform ed on t he proj ect . Tim esheet s are sim ple in principle and have t he advant age of offering inform at ion t hat com es direct ly from t he people who are act ually doing t he proj ect t ask s. Tim esheet s are useful t o any proj ect and should be subm it t ed by t eam m em bers on a ( 1) weekly, ( 2) sem i- m ont hly, or a ( 3) m ont hly basis. These t im e sheet s indicat e t he proj ect t asks t hat resources are working on ( e.g., John worked 180 hours on WBS it em 20.4.3 for t he m ont h of July) and are aut horized eit her by t he proj ect m anager or client . The t im esheet s are consolidat ed and used accordingly for billing or invoicing purposes. I f t im esheet s are an im port ant part of t he invoicing cycle, the proj ect m anagers m ust be m ade aware of t he ant icipat ed cash flow at each m ont h by t he cont ract ing t eam . Lat e or delayed t im esheet s affect t his cash flow and also affect t he com pany's financial posit ion. The proj ect m anager should also consolidat e t he hours worked per WBS it em and capt ure t hese work - hours against t he budget ed planned hours. Today, m any proj ect soft ware t ools allow for t im esheet capt uring. Daily Proj ect Act ivit ies Check list A vit al part of any proj ect m anager's responsibilit ies is t o t ake charge of t he day- to - day act ivit ies on t he proj ect . These include m onit oring t he progress of proj ect t asks and act ivit ies and m aking decisions about t he proj ect . Most im port ant ly, t hese t asks and act ivit ies should be m anaged on a daily or weekly basis. The best way t o gat her t his proj ect inform at ion is t o ask t he proj ect t eam m em bers how t heir t asks are progressing. Proj ect m anagers have com e t o underst and t hat not hing subst it ut es for act ually asking t eam m em bers, face t o face, how t heir part of t he proj ect is going. Proj ect m anagers are m uch m ore likely t o get a t rue pict ure of t he fact s. They t hen incorporat e and updat e t his progress inform at ion int o t he respect ive proj ect

docum ent at ion. Table 7.3 shows which docum ent at ion needs t o be cont rolled on a regular basis. Ta ble 7 .3 : Frequency check list W hat

How t o Updat e

Frequency

Proj ect definit ion report or plan

Updat e exist ing docum ent s

As needed

The weekly proj ect st at us report

I ssue new st at us report

Weekly

Daily issue and risk log

Updat e issue or risk log

Daily

Com put erized t racking t ools

Review and t rack

Daily

Change request form s

Subm it changes t o change cont rol board ( CCB)

As needed

Rem em ber t hat t he proj ect execut ives rely on t he proj ect m anager's st at us report s and com m unicat ions when t hey are reviewing and m aking im port ant st rat egic decisions. I f t hese docum ent s show t hat a proj ect is behind schedule or over budget , t hen it fuels t he quest ion as t o whet her execut ives need t o cancel t he proj ect ent irely or see it t hrough t o t he end, as it is st rat egically im port ant from a business perspect ive. Nonet heless, t he proj ect m anager is t he person account able for report ing t he accurat e and t rue st at us of t he proj ect at frequent int ervals ( see Figure 7.6 ). I have personally found t hat subm it t ing st at us report s on a weekly basis works best .

Figure 7 .6 : Daily proj ect act ivit y checklist CON TROLLI N G PROJECT RI SK Risk cont rol is t he process of cont inually assessing t he condit ion of t he proj ect and developing opt ions t o perm it alt ernat ive solut ions ( see Figure 7.7 ) . Proj ect m anagers should t ake care t o ident ify consequences t hat are likely t o occur and any indicat ors of t he st art of t he problem . The following are som e suggest ions for risk cont rol: •

Cont inually updat e t he risk m anagem ent plan.

•

I m plem ent risk avoidance act ions.

•

I m plem ent risk cont ingency act ions.

•

Report on each risk issue.

•

Monit or and analyze t he effect iveness.

Figure 7 .7 : Cont rol issues t o m onit or Updat ing t he Proj ect Risk Log Risk quant ificat ion involves t he process of evaluat ing risks and det erm ining t he effect t he risk will have on your proj ect . One of t he easiest ways t o det erm ine risk quant ificat ion of proj ect risks is t o m ult iply t he pot ent ial im pact ( I ) of t he risk's occurrence wit h t he probabilit y ( P) of it occurring. The probabilit y of occurrence is t he degree of belief t hat various event s will occur. The pot ent ial severit y of im pact is t he significance of t he event if it happens. Once quant ified, each risk needs t o be priorit ized by t he proj ect m anager ont o a risk m at rix. This act ion ensures t hat effort s are fo cused on only t he m ost significant ones. The form ula com m only used is R = I ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ Risk ( % ) = I m pa ct ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ ？ I = Assign a value bet ween ( 1- 10) t he im pact it will have. P = Assign a value bet ween ( 1 -10) t he probabilit y of it occurring. Once t he value( s) have been det erm ined, t he proj ect m anager allocat es a percent age ( % ) t o t he risk, and t his t hen allows him or her t o cat egorize

and priorit ize t he ident ified risk. Table 7.4 gives an exam ple of a risk and issue m at rix. The risk ( % ) is t abled as follows: •

> 80 = Priorit y One

•

> 50 – 79 = Priorit y Two

•

> 30 – 49 = Priorit y Three

•

< 30 = Priorit y Four

Ta ble 7 .4 : Risk and issue m at rix ID

Proj ect Ar e a

Descript ion of Risk

1

Client

2

3

I

P

Score

Solut ion

Need URS signed off— ver 1.0

9

9

81

Begin negot iat ions

CCB

New change request — new dat abase

7

7

49

Review change req.

Design

Hardware spec t o be finalized

6

5

30

Finalize by 10/ 1

The risk m at rix prim arily works ext rem ely well and let s proj ect m anagers proact ively docum ent and resolve all ident ified issues and risks m ade during t he proj ect life cycle. As t he proj ect cont inues, risks ident ified early on in t he planning phase will be resolved and t he event ualit y of new ones being raised during t he lat er phases is good. Proj ect m anagers need t o be prepared for risks and t he difficult y and rat e at which t hey surface. Each risk needs t o be docum ent ed, irrespect ive of t he rat ing it is given. The risk m at rix should form t he basis of a working proj ect docum ent , and it needs t o be form ally com m unicat ed t o all proj ect st akeholders in order for t hese st akeholders t o obt ain a current perspect ive on t he proj ect . I once observed a proj ect m anager t rying his very best t o resolve proj ect risks in t ot al isolat ion, and t his led t o com m unicat ion problem s and t he event ual cancellat ion of t he proj ect by execut ives—all because t hey could not see a visible proj ect leader and had no assurance as t o t he proj ect being in control. I dent ifying I ssues I t is necessary t hat proj ect m anagers ident ify issues as quickly as possible in order t hat t hey be addressed and resolved. I t em s t hat do

surface during t he proj ect life cycle t hat require follow- up m ust be capt ured in an I ssue Log and be resolved quickly. I n order t o ident ify any proj ect issues, it is also im port ant t hat t he proj ect m anager knows which quest ions t o ask during t he course of proj ect m eet ings and reviews. The problem is t hat when working on a proj ect , t he people who are t o provide t he answers are not always available t o do so, so t he proj ect m anager needs t o t ake t he lead and do what ever it t akes t o get t he necessary answers. PROJECT CHAN GE CON TROL Change can be generat ed by anyone, but t his is not t o say t hat t he required change will be act ually im plem ent ed on a proj ect . Changes t o a proj ect m ay be a result of a ( 1) deviat ion or waiver, ( 2) issue m anagem ent process, or ( 3) a change in scope as request ed by t he client . I f a deviat ion is ident ified from t he agreed- upon assum pt ions and const raint s, or if t he client is unwilling t o m eet t heir obligat ions, a change in t he proj ect or t he proj ect t arget s m ay result . Resolving an issue m ay m ean changing t he way t he proj ect is being approached or changing sco pe. I n m any cases, t here m ay be a clear m odificat ion t o scope wherein t he client request s addit ional funct ionalit y or deliverables, or perhaps even a reduct ion in funct ionalit y or deliverables. Developers and designers som et im es int roduce t echnical "requir em ent s" t o a proj ect t hat do not act ually cont ribut e t o t he business success of t he proj ect . Essent ially, no m at t er how "nice" som et hing is, it should not be done unless t here is a clear business benefit t hat is wit hin t he scope of t he proj ect . Proj ect m anagers should at least be aware of new requirem ent s before t hey are im plem ent ed. Many proj ect s suffer from users, business analyst s, and even t echnical archit ect s wandering from developer t o developer and insert ing "good ideas" int o t he proj ect . While t his is done wit h t he best of int ent ions, it has a t errible im pact on t he schedule and m ust be cont rolled. This is not t o say t hat all "t echie" t asks should be dism issed out of hand; however, t hings t hat are necessary should be sold t o t he business on t he basis of benefit t o t he business, and t hey should be included in t he business requirem ent s for t he proj ect . Table 7.5 illust rat es a change cont rol t racking spreadsheet t hat list s all t he change request s approved on t he proj ect . The schedule and cost effect can also be t aken int o account .

Ta ble 7 .5 : Change cont rol t racking list

ID

Descript ion of Change Re que st

Subm ission Date

Schedule I m pact

Cost I m pact

St a t us

1

Change web UI pick list

9/ 29/ 01

4 days

$7,000

Approved

2

Modify m ont h end report

03/ 24/ 02

2 weeks

$6,000

Approved

3

Migrat e dat a t o new plat form

10/ 20/ 01

2 m ont hs

$80,000

Cancelled

4

I nclude search engine XYZ

10/ 28/ 01

1 m o nt h

$14,000

Pending

N et Proj ect I m pact ( Approved Change Re que st s)

$13,000

Change Cont rol: A Process I t is im port ant t o cont rol t he change request s t hat are proposed during t he course of t he proj ect . The following st ep- by- st ep process will help proj ect m anagers im plem ent successful change cont rol. 1. I nit iat e scope change request s by com plet ing a scope change

request form . 2. Track scope change request s by logging t hem in a scope

change cont rol log. 3. Det erm ine how t he scope change will be ident ified and

prioritized. 4. Assess t he im pact ; exam ine t he t asks, schedule, cost , and

qualit y affect ed by t he scope change. 5. Select t he recom m ended solut ion t o t he scope change. 6. Meet wit h t he owner t o accept or rej ect t he change. 7. I m plem ent t he scope changes order, if required, and docum ent

t he changes.

8. Com m unicat e t o t he proj ect t eam so all m em bers underst and

t he affect of t he scope change. Changes t o t he Proj ect Scope Change m anagem ent ensures t he sm oot h int egrat ion of t he exist ing ( product ion) code and operat ing syst em wit h any planned int roduct ion of an alt erat ion, variance, or im provem ent . The change m anagem ent process is invoked whenever changes are being int roduced int o t he t arget ed environm ent . Dealing w it h Version Cont rol Once approved, all proj ect docum ent at ion and plans should be referred t o as t he baseline plan. Rem em ber t hat plans are oft en revised and it is com m on for proj ect m em bers t o work wit h different or out dat ed docum ent s or plans. Therefore, all plans should be m anaged and placed under st rict configurat ion m anagem ent . The proj ect m anager's prim e direct ive is t o ensure t hat all changes m ade t o proj ect docum ent at ion are capt ured correct ly and approved accordingly. The docum ent at ion should also reflect t he appropriat e version num ber, dat e, and an index of all changes m ade t o t he respect ive docum ent before it is dist ribut ed t o proj ect m em bers. Tracking Changes There are m any configurat ion m anagem ent t ools on t he m arket t hat richly deserve credit for t heir abilit y t o t rack changes t o bot h soft ware and t o t he developm ent process. Som e are m ore com plex t han ot hers and offer incredible perspect ives on t he changes about t o be m ade t o syst em s. Proj ect Managers need t o t rack all proposed changes t o t he proj ect on an ongoing basis. Change Cont rol Board Responsibilit ies Any ant icipat ed changes t o a proj ect need t o be reviewed from a t echnical and business perspect ive before any proposed change can t ake effect . The change cont rol board ( com m only know as "CCB") consist s of a chairperson and t echnical and business m em bers who appoint subj ect m at t er expert s on an " as- needed" basis. They m eet on a frequent basis t o review t he change request s or when request ed by t he proj ect m anager. Very oft en at large organizat ions, it is com m on t o find a dedicat ed CCB in place, serving all change request s wit hin t he proj ect and operat ional environm ent . I n t his case, t he proj ect m anager needs t o det erm ine t he process of funct ions wit hin t he CCB. The CCB can perform t he following:

•

Approve change request s m ade t o t he proj ect

•

Rej ect t he change request

•

Defer t he change request unt il furt her assessm ent s or recom m endat ions are m ade

Norm ally, an average- sized proj ect cannot afford t he m anpower and t he t im e t o develop t hese change processes from scrat ch, so it is oft en left t o t he proj ect m anager t o form his or her own CCB, oft en involving t he client in t he process. Cont rolling Conflict on t he Proj ect On alm ost every proj ect , t he pot ent ial for conflict arises at som e point . This is a nat ural t rend. The proj ect m anager should work proact ively wit h all st aff t o avoid possible conflict s t hat m ay arise. I n t he event of a conflict , t he proj ect m anager should be aware t hat t alking can only resolve so m uch. For sit uat ions where conflict cannot be resolved t hrough negot iat ions or arbit rat ion, it is recom m ended t hat t he identified individuals be separat ed or be rem oved from t he proj ect . I t is im port ant t o underst and t hat proj ect st aff react different ly t o daily sit uat ions and t hat during t he proj ect life cycle, t hese m em bers all experience various em ot ions such as j oy, sadness, j ealousy, anger, frust rat ion, and st ress—t o nam e but a few. Many conflict s can be reduced or elim inat ed by const ant ly com m unicat ing t he proj ect obj ect ives t o t he proj ect t eam m em bers. Som e of t he m ost com m on conflict s are •

Conflict over proj ect priorities

•

Conflict over adm inist rat ive procedures

•

Personalit y conflict s

•

Lack of respect for one anot her

•

Conflict over t echnical opinions and perform ance

•

Conflict over st affpower resources

•

Conflict over cost

•

Conflict over schedules

When conflict s do arise, t here are several m et hods t o t ry t o resolve t hem .

1. Com prom ise. Part ies consent t o agree; each side wins or loses

a few point s. 2. Confront at ion. Part ies work t oget her t o find a solut ion t o t he

problem . 3. Forcing. Power is used t o direct t he solut ion. One side get s

what t he ot her does not . 4. Sm oot hing. This t echnique plays down t he differences bet ween

t wo groups and gives st rong at t ent ion t o t he point s of agreem ent . 5. Wit hdrawal. This t echnique involves one part y rem oving him -

or herself from t he conflict . M AN AGI N G QUALI TY For t he proj ect m anager, qualit y m anagem ent is all about ensuring t hat everyt hing t hat is done or produced fit s t he purpose for which it is being done or produced. There are t wo m ain facet s t o qualit y m anagem ent : ( 1) qualit y assurance ( QA) and ( 2) qualit y cont rol. I n order t o perform t est ing effect ively in a soft ware developm ent effort , t he QA m anager needs t o det erm ine ways t o show progression and im provem ent of t he process and of t he deliverable product . Measuring t he effect iveness of t est ing serv es t he following purposes: •

Evaluat es t he perform ance of t est ing t o uncover defect s

•

Quant ifies t he qualit y of t he program / applicat ion process

•

Provides a confidence fact or t o predict pot ent ial occurrences of errors once t he syst em is released

•

Provides dat a for pot ent ial im provem ent opport unit ies

•

Just ifies t he expenses of t he unit / resources t o cont ribut e t o t he end product 's usefulness

The post im plem ent at ion review process provides a st ruct ure for ident ifying opport unit ies for cont inual im provem ent . I t assesses t he result s of a release or of an ent ire syst em . The QA m anager is oft en responsible for developing indicat ors for t he review. The int ent is t o develop a pict ure of what was successful in t he process of developm ent and t est ing and what m ight be im proved. I ndicat ors are agreed upon in advance during syst em developm ent and are docum ent ed in a t em plat e.

Updat ing Proj ect Docum ent at ion I t is im port ant t hat , t hroughout t he proj ect 's life cycle, proj ect m anagers updat e and dist ribut e all new approved changes t o t he exist ing proj ect docum ent at ion in order t o reflect any changes t o t he proj ect plans or schedule. A dist ribut ion list developed during t he init iat ion phase should det ail t he recipient s, com m unicat ion m et hods, and num ber of copies required. Conduct ing Qualit y I nspect ions Proj ect m anagers should obt ain feedback from t he proj ect owner, st akeholders, or bot h t o det erm ine t hat t heir qualit y requirem ent s are being m et . He or she should m ake sure t hat t he proj ect t eam m em bers report com pliance or noncom pliance t o t he qualit y plan, specificat ions, and procedures. Throughout t he proj ect 's life cycle, t he proj ect m anager should generat e report s t hat are relat ed t o qualit y issues and perform ance, as well as perform periodic qualit y audit s. He or she should record lessons learned t hat address any qualit y issues or problem s encount ered in t he proj ect and t he associat ed resolut ions. Qualit y Assurance QA involves all planning, design, work, and procedures necessary t o ensure t hat qualit y is achieved—in ot her words, t o ensure t hat what is done or produced is fit for it s purpose. Hence, QA can be t hought of as act ivit y t hat t akes place before any work is done. Qualit y Cont rol Qualit y cont rol is t he inspect ion of finished product s t o ensure t hat t hey m eet required st andards or are fit for t heir purpose. Where product s fail, rem edial act ion is t aken. Thus, qualit y cont rol is norm ally considered som et hing t hat goes on aft er t he work has been done. I t m akes no sense at all t o keep on doing t hings wrong in t he hope t hat m ist akes will be picked up and rect ified in qualit y cont rol.

Figure 7 .8 : Qualit y assurance and cont rol Proj ect St at us Report ing Throughout all individual phases of t he proj ect , t he proj ect m anager is required t o develop and dist ribut e regular proj ect st at us report s t o key st akeholders who are involved wit h t he proj ect . Rem em ber t hat st at us report s keep everyone inform ed of t he current st at us of t he proj ect and t he progress being m ade. This report also highlight s any unresolved issues or act ion it em s. I t em s t hat are part of proj ect st at us report ing include •

Execut ive high- level proj ect schedules

•

Periodic st at us report s

•

Weekly st at us report s

•

Mont hly proj ect st at us report s

•

Proj ect sum m ary report s

High- level or sum m ary proj ect schedules are great when you have m ore t han 100 t asks and want t o provide execut ives wit h a snapshot of w here t he proj ect is, from a schedule perspect ive. Execut ives rarely have t he t im e t o browse t hrough a com plex schedule wit h m ore t han 100 t asks in it . Rat her, a short sum m ary explains m at t ers far m ore clearly t han a det ailed schedule. The sum m ary - level schedule should filt er t hose t asks t hat are on a high level only. Figure 7.9 illust rat es an exam ple of a highlevel sum m ary schedule.

Figure 7 .9 : High- level execut ive sum m ary As t he proj ect m anager m oves forward on a proj ect , inform at ion changes and progress updat es are m ade t o t he baseline proj ect plan and schedule. Whenever such progress updat es are m ade, it is wise t o include t hese changes int o t he st at us report as well when reviewing a proj ect or proj ect s wit h t he supervisor. Organizat ions usually have t heir own st at us report form at t hat t hey would like t o m onit or, so it is im port ant t o underst and what progress inform at ion t o present . The following is som e of t he m ost com m on inform at ion t hat I have found proj ect m anagers like t o include in t heir proj ect st at us report s: •

Proj ect nam e

•

Proj ect num ber

•

Proj ect m anager

•

Client

•

Cont ract am ount

•

Current proj ect phase ( e.g., SDLC phase)

•

Upcom ing t asks for t he com ing period

•

Tasks or m ilest ones com plet ed

•

Percent age com plet e

•

Whet her t he proj ect is ahead or behind t im e schedule

•

Whet her t he proj ect is over or wit hin t he cost schedule

•

Num ber of change request s subm it t ed since proj ect st art

•

Correct ive act ions ( if necessary)

•

Risks and issues t hat require urgent at t ent ion

•

Resource st at us

•

A cat egorizat ion syst em for t he st at us report ( e.g., t he color red for "in danger," yellow for "in t rouble," and green for "OK"

Wit hin m any organizat ions, it is com m on t o hold a general st at us report m eet ing where each proj ect m anager has t he opport unit y t o report back t o t he group on t he progress of each proj ect . The group, in t urn, has t im e t o assist t he proj ect m anager wit h possible solut ions or ways t o correct problem s. I found t his t o work well at a cellular com pany; one proj ect m anager st at ed, "These m eet ings help m e t o resolve issues and risks t hat I didn't know how t o solve. I t helped m e t rem endously and also fost ered a t eam spirit am ong m y colleagues." I t is j ust as com m on for st at us report s t o be handled on a one- for-one basis w it h only t he proj ect sponsor or supervisor. So, it is necessary t hat proj ect m anagers det erm ine t he t ype of st at us report ing t hat is required, t he m anner in which it is present ed, and t he frequency of t hese st at us report s. LESSON S LEARN ED FOR CON TROLLI N G THE PROJECT •

Mot ivat e proj ect t eam m em bers and creat e incent ives for t eam work.

•

Deliver on prom ises t o t eam m em bers. Unfulfilled expect at ions can lead t o negat ivit y and poor perform ance.

•

Never have argum ent s or conflict in front of ot hers.

•

Ensure t hat t he proj ect obj ect ives have been clearly defined.

•

Ensure t hat a risk m anagem ent plan exist s for any pot ent ial risk t hat m ay t ake place.

Figur e 7 .1 0 : Generic proj ect st at us report

Phase Com plet ion Checklist The proj ect m anager should ensure t hat t he following proj ect processes and docum ent at ion are im plem ent ed for t his phase t o be com plet e: •

A m onit oring process

•

Sum m ary- level schedule for execut ive t eam

•

Tracking schedule ( GANTT chart )

•

Cert aint y t hat t he proj ect t eam knows what t o m onit or

•

Earned value spreadsheet ( if required)

•

Except ion report s

•

Updat ed proj ect plan

Ch a pt e r 8 : I m ple m e n t in g t h e Pr oj e ct SUCCESSFUL I M PLEM EN TATI ON : GETTI N G I T RI GH T! Get t ing t he im plem ent at ion phase right t he first t im e is crucial for any proj ect m anager or proj ect t eam . This chapt er offers guidelines for successfully im plem ent ing a proj ect and ensuring t hat all relevant areas have been addressed. Rem em ber t hat everyt hing t he proj ect t eam planned, developed, and changed t hroughout t he proj ect life cycle is now ready for im plem ent at ion. I m plem ent at ion, in a nut shell, refers t o t he efficient t ransfer of t he proj ect int o t he client 's "live" product ion environm ent . The logist ical deploym ent of t he proj ect int o t he business operat ion is oft en com plex and needs close coordinat ion by t he proj ect t eam . The users of t he fut ure syst em are anxiously wait in g for t he new solut ion and m ost probably have been briefed as t o when t he solut ion will be im plem ent ed and "up and running." I f t he product ion m anager fails t o deliver at t he specified t im e and wit hin t he designed funct ionalit y, problem s are bound t o occur. There is no t urning back! I n t his chapt er I show how t o im plem ent a syst em and support it at a low cost . Failure t o deploy a proj ect correct ly is one of t he m aj or causes of proj ect failure. This chapt er addresses t he causes of poor deploym ent and highlight s recom m endat ions for a successful one. The im plem ent at ion of t he solut ion is not final unt il sufficient at t ent ion is paid t o ensure t hat client is knowledgeable and has been t rained t o use t he solut ion. Training t he client st aff can t ake up considerable proj ect resources, oft en a significant proport ion of t he overall cost of t he proj ect . Therefore, t he t raining should be carefully planned and budget ed. The st aff who will m aint ain and support t he solut ion once it is im plem ent ed should also be offered t raining. I MPLEMEN TATI ON APPROACHES There are a variet y of opt ions t hat a proj ect m anager could consider when im plem ent ing a solut ion. There are advant ages and disadvant ages t o each t ype, and t he choice usually depends on t he client organizat ional set up and t he com plexit y of t he solut ion t o be im plem ent ed. For exam ple, an int ernat ional client wit h m ult iple offices needs t o upgrade a cert ain em ail syst em in all offices by a cert ain "go - live" dat e. I n such a scenario, a proj ect m anager is faced wit h huge logist ical and t echnical challenges, and t he im plem ent at ion st rat egy is pivot al in deciding on t he rollout . These im plem ent at ion choices available t o a proj ect m anager are Parallel im plem ent at ion Phased im plem ent at ion Crash im plem ent at ion

Parallel I m plem entation A parallel im plem ent at ion or approach im plies t hat a new solut ion is im plem ent ed parallel t o t he current operat ional syst em in use. Those who are using t he syst em will not see m aj or downt im e once it is im plem ent ed. The t rick here is t o im plem ent t he syst em . Once t he new solut ion is t est ed and up and running, it is "swit ched" on and t he older version is "swit ched" off. The advant ages wit h a parallel im plem ent at ion include ( 1) less disrupt ion t o t he business, and ( 2) no loss of business if t he new sy st em suddenly fails. Phased Approach Som et im es t rying t o im plem ent a solut ion all at once is not feasible because m any client s have essent ial operat ions t hat run during norm al working hours and cannot afford t he luxury of having t heir ent ire operat ion close down for a lengt hy period in t im e. Oft en, client s have front office st aff t hat at t end t o t hese operat ions ( such as call cent ers, help desks, et c.) , and t hey work in 24- hour shift s. This is why m any client s approve of a phased im plem ent at ion approach, and t he proj ect t eam m ust ensure t hat t he phased im plem ent at ion is possible. This approach involves im plem ent ing t he solut ion t o a cert ain am ount of users and t hen rolling t hem ont o t he new solut ion, while t he rest of t he users are rolled out in a sim ilar fashion, unt il t he ent ire solut ion is rolled out wit hin t he client environm ent . The phase approach works well because ( 1) t here is m inim al disrupt ion t o t he client s operat ion, and ( 2) problem s are resolved quicker. The phased approach could also be used if t here is m ore t han one depart m ent . The proj ect m anager could decide t hat im plem ent ing t he solut ion in one depart m ent at a t im e could be m ore reliable t han t rying t o roll out all depart m ent s at t he sam e t im e. Crash I m plem ent at ion Careful planning needs t o t ake place when considering a crash ( also known as full- blown) im plem ent at ion. I t t akes an incredible am ount of planning and re- planning t o ensure no problem s arise. I n fact , wit h t his t ype of im plem ent at ion, t he necessary cont ingencies need t o be prepared and reviewed well in advance of t he act ual im plem ent at ion, in order t o m inim ize any pot ent ial failure. The necessary I T support st aff also need t o be available on t he chosen im plem ent at ion period. A full- blow n im plem ent at ion should be scheduled t o t ake place over a slow period, such as a holiday or weekend.

I m plem ent at ion Checklist The proj ect m anager m ust be sure t hat t he im plem ent at ion follows t he im plem ent at ion t asks and act ivit ies as st at ed in t he proj ect schedule. This form s the basis against which the im plem ent at ion will be done. Generally, t he t asks would be t o Load or inst all t he new syst em Perform a syst em t est Convert t o t he new syst em Verify t hat an applicat ion works wit h ot her applicat ions in t he syst em Perform an int egrat ion t est Per form an accept ance t est The I m plem ent at ion Plan The im plem ent at ion plan, which was developed by t he proj ect m anager during t he design phase, should, at t his st age, be approved and com m unicat ed t o all proj ect st akeholders. A successful proj ect can be ruined by a poor im plem ent at ion plan. A working im plem ent at ion schedule should be developed and m aint ained for all part ies t o use and agree upon. As t he proj ect changes, t he proj ect m anager m ust pay close at t ent ion t o t he schedule and updat e it t o reflect t he lat est changes t o t he im plem ent at ion dat e. This schedule should t hen be com m unicat ed t o all proj ect st akeholders. I t is im port ant t o publish an init ial im plem ent at ion schedule for each sit e early in t he proj ect . Many m em bers of t he deploym ent proj ect t eam will reach a point where t hey cannot unt il t hey know t he t im e, sequence, or dat e of t he im plem ent at ion. Experience has shown t hat developing a draft im plem ent at ion schedule early in t he proj ect life, rat her t han lat er, resolves m any problem s. The proj ect m anager should rem em ber t hat t he im plem ent at ion plan could be put on hold if t he soft ware developm ent is lat e for what ever reason. However, if t he im plem ent at ion plan cannot be m oved and t here is no slack in t he schedule, t he proj ect m anager should im m ediat ely escalat e t his risk t o t he necessary st akeholders. Meet ings Leading up t o I m plem ent at ion The im plem ent at ion plan m ust be discussed and agreed upon by bot h t he user m anagem ent and I T support st aff in order t o ensure t hat bot h part ies plan t heir work schedules t o m at ch t he proj ect schedule. For t he m aj orit y of I T proj ect s, im plem ent at ion will m ost likely occur aft er hours or over weekends, during a series of working hours per day, or on public holidays.

QUALI TY ASSURAN CE QA is oft en seen as an int egral funct ion t hat m onit ors and coordinat es t he qualit y used wit hin t he proj ect m anagem ent life cycle by evaluat ing t he processes and procedures. Qualit y cont rol, on t he ot her hand, can be seen as a focused area ( such as soft ware t est ing) t hat com pares t he product to t he specificat ion or plan, wit h a focus of det ect ing and rem ediat ing errors or anom alies. The Role of QA on t he Proj ect The person who is responsible for QA has m any dut ies and responsibilit ies. The following sect ion list s m any of t he t hings t hat a QA person would be expect ed t o do. ?

?

?

? ? ? ?

?

Part icipat e in t he change m anagem ent process t o assess t he risk of put t ing fixes int o t he environm ent during accept ance t est ing. Assist t he t est t eam in isolat ing t he source of discrepancies bet ween expect ed and act ual t est result s. I f t he error is in soft ware design, t horoughly analyze t he ram ificat ions of any design changes. Design diagram s and st ruct ure chart s before proceeding wit h correct ions t o code. Com plet e preparat ions for accept ance t est ing, including t he est ablishm ent of t he accept ance t est environm ent . Unlike syst em t est ing, accept ance t est ing always t akes place in t he t arget ed environm ent . I t is t herefore ext rem ely im port ant t o schedule com put er resources well in advance. Check t he sim ulat ed dat a t o ensure t hat required t est dat a have been produced. Obt ain expect ed result s from t he accept ance t est plan and review t hem for com plet eness. Calculat e any m issing expect ed result s. Be cert ain t hat t he int roduct ion of new load m odules is according t o t est configurat ion m anagem ent procedures. When a new, correct ed load m odule is received, first rerun t est s t hat previously failed because of soft ware errors. I f t hese t est s succeed, proceed wit h regression testing. Analyze and report t est result s. Evaluat e t est result s as soon as possible aft er execut ion. Wherever possible, use aut om at ed t ools in t he analysis process. Record analysis procedures and keep all relevant m at erials. Rem em ber t hat records and report s should give com plet e account s o f t he procedures followed. I f a t est cannot be

?

evaluat ed, not e t he fact and report t he reasons for it . Com pare all t est result s wit h expect ed result s and not e t hat all defect s are docum ent ed, regardless of how m inor t hey appear or whet her t hey will be correct ed.

PREPARI N G TH E I N FRASTRUCTURE The planning for and preparat ion of t he solut ion infrast ruct ure prior t o t he act ual im plem ent at ion is an im port ant st ep. Once t he physical facilit y has been ident ified, t he following aspect s need t o be m anaged by t he proj ect team : ? ? ?

That sufficient power and workst at ions exist for all t he users and equipm ent That sufficient workspace exist s for all t he ident ified users That net work connect ivit y can be est ablished bet ween users and services or syst em s

Equipm ent Set up and Configurat ion I t is im port ant t hat t he necessary hardware and soft ware is ( 1) shipped, ( 2) delivered, ( 3) inst alled, and ( 4) configured correct ly t o reflect t he requirem ent s of t he solut ion prior t o t he go - live dat e. The proj ect m anager needs t o t rack and coordinat e all I T equipm ent in support of t he ent ire proj ect im plem ent at ion. I rem em ber a proj ect t hat was perform ing a web sit e m igrat ion and had a cert ain go - live dat e, but failed t o have t he hardware delivery dat es confirm ed wit h t he suppliers. The hardware was delivered six weeks behind schedule and t he t eam had t o m ake use of replacem ents until the ordered hardware arrived. This exam ple clearly shows t he im port ance of t he m anaging t he I T equipm ent necessary for im plem ent at ion. Even delivery schedules m ust be confirm ed from t hird part y cont ract ors t o com m it t o t he m ast er proj ect schedule. N et w ork s Access t o Users Once t he necessary solut ion is nearing t he act ual go - live dat e, t he proj ect m anager should have a com plet e list of aut horized users who will need access t o t he new syst em . This list is prepared prior t o im plem ent at ion because t he t ask of obt aining user login passwords inform at ion can t ake t im e. The new I T solut ion should be configured t o accept each aut horized user of t he new solut ion.

TRAI N I N G THE CLI EN T Training and Know ledge Transfer Frequent ly, users of t he solut ion are eit her not t rained properly or t hey are not t rained at all, which result s in rej ect ion of t he solut ion wit hin t he client organizat ion. I t is im port ant t hat users of t he syst em receive all t he t raining and support t hey need t o use t he new syst em effect ively. The im plem ent at ion of an I T syst em is not an end in it self. I t is im port ant t hat st aff m em bers are able t o use it and t hat t he im pact of it s int roduct ion on t heir product ivit y has been fully considered during t he planning st age. Wit hout t hese considerat ions, is it is unlikely t hat t he ant icipat ed business benefit s will be realized. Training of st aff can t ake up considerable resources, oft en a significant proport ion of t he overall cost of t he proj ect . Training m ust address t he needs of users and of t hose operat ing and m aint aining t he syst em . The proj ect m anager has a few opt ions when it com es t o t raining resources on t he developed solut ion: ? ? ?

Out source t he t raining t o a reput able, accredit ed t raining vendor. Provide the training in - house at t he client . Provide t he t raining at t he proj ect m anager's organizat ion.

Proj ect m anagers need t o realize t hat proper t raining m ust be provided t o t he users of t he solut ion, and t he following t ypes of t raining can be provided before t he solut ion is im plem ent ed and delivered for use: ? ? ? ?

Classroom - based lect ures One-on-one sessions Self- paced, com put er- based tutorials Providing t he user wit h an operat ions m anual

Sufficient t im e and resources should be spent in order t o help t he st aff learn how t o use t he I T syst em . Considerat ion should be given t o t he possible effect t he new syst em m ay have on product ivit y in t he period following im plem ent at ion. I n part icular, it is im port ant t o m ake a realist ic assessm ent of t he im pact t hat int roducing t he new I T syst em will have on t he product ivit y and effect iveness of st aff. Addressing t he Training I nfrast ruct ure Providing t he t raining for users at a suit able t raining locat ion is im perat ive in ensuring t hat t he users are sat isfied wit h t he qualit y of t he solut ion being im plem ent ed. I f t he t raining facilit y is sit uat ed at t he back

of t he office, it im m ediat ely gives users t he im pression of an inferior solut ion. Sufficient t hought and user acknowledgem ent m ust be given t o t raining, and it st art s by m aking sure t hat t he users have ( 1) adequat e t raining m at erial, ( 2) t raining in a proper facilit y, and ( 3) t he correct t raining resources. Using t hese t hree fact ors can only result in successful training. Once t raining has been synchronized wit h t he im plem ent at ion schedule and approved by all t he st akeholders, it becom es necessary t hat t he syst em is t est ed and fully funct ional by t he t im e t hat user st aff ret urn t o t heir environm ent . Technica l Support Tra ining Before im plem ent ing a proj ect for a client , t he proj ect m anager should be sure t hat t he client I T operat ional support st aff are adequat ely t rained and knowledgeable on t he t echnical support issues of t he syst em being com m issioned. Aft er all, t he I T support st aff are responsible for m aint aining t he various t echnologies and plat form s once t he proj ect is handed over. Table 8.1 displays t he various levels of support t hat a proj ect m anager should discuss wit h t he support st aff prior t o proj ect im plem ent at ion. Ta ble 8 .1 : Support levels t ha t need t o be a ccom m oda t ed Support Le ve l

Focuses on

Level 1

Basic set up and rest orat ion of funct ions. Can be perform ed in - house.

Level 2

I nterm ediate- level repairs wit hin IT depart m ent . Can be perform ed in - house.

Level 3

Com plex t echnical support required wit h t he solut ion provider/ supplier.

I t is som et im es t he proj ect m anager's responsibilit y t o see t hat cert ain m em bers of a client help desk operat ion ( who deal m ainly wit h t echnical queries and problem s) are also provided wit h t echnical t raining t o assist t hose individuals who m ay have problem s wit h t he newly com m issioned I T syst em . I t is not always sufficient t o provide only t raining for t he client st aff. Som e of t he necessary it em s t o provide in addit ion t o t he t raining are ? Proper m aint enance m anuals, including checklist s, for each level of support ? An approved and relevant service level agreem ent ( SLA) cont ract bet ween supplier/ client ? An approved cont ingency plan

?

Sufficient quant it ies of spare part s held for all crit ical it em s likely t o fail

I m plem ent at ion Day The im plem ent at ion or go - live dat e for a new solut ion requires det ailed planning, significant effort from bot h client and supplier, and t he involvem ent of t he st akeholders. The proj ect m anager leads t his effort by bringing everyone t oget her for t he go - live dat e. The proj ect m anager should repeat edly check and double- check t he im plem ent at ion t asks and responsibilit ies prior t o t he go - live date until t hey are second nat ure. I t is not accept able for t he proj ect m anager t o review t he proj ect schedule t oo lat e and accordingly arrange t he init ial go - live m eet ing on t he act ual dat e of im plem ent at ion. This will not work. I cannot overem phasize here t he im po rt ance of proper com m unicat ion. The proj ect m anager m ust underst and t hat serious pressure t o com plet e t he im plem ent at ion will result in business obj ect ives being lost . The proj ect m anager m ust ensure t hat t he processes for delivering t he solut ion benefit s include t he following: ? ? ?

?

?

The necessary proj ect resources are available for t he go - live dat es. The schedule correct ly reflect s det ailed proj ect t asks and act ivit ies. The I T help desk is aware of t he go - live date and has been briefed as t o t he possible volum e and nat ure of calls t hat could be expect ed. A conference bridge t elephone num ber has been reserved for everyone t o use for t he durat ion of t he go live dat e. The client is inform ed about t he go - live act ivit ies and t he role t hat t he client will play in im plem ent ing t he solut ion.

I m plem ent ing over W eekends or Holidays I t is com m on t o im plem ent I T proj ect s over quiet periods, such as weekends or even over holidays, in order t o m inim ize any disrupt ions. The proj ect m anager m ust suit ably plan t he go - live period, and he or she cannot assum e t hat it is t he dut y of t he t est t eam t o prepare t he next st ep in t he im plem ent at ion. The proj ect m anager should com plet e t he following act ivit ies: ?

Creat e and circulat e a prim ary and secondary cont act list of key im plem ent at ion st aff.

? ?

?

?

Prearrange access t o t he facilit ies and I T syst em s. Est ablish a conference bridge num ber over t he weekend or holiday. This can be scheduled at cert ain t im es or be st affed full- t im e. Consider opening up a st at us line. Regular voice m ail proj ect st at us can be left for all proj ect st akeholders in order t o brief t hem on t he proj ect progress. Once t he proj ect has been im plem ent ed successfully, send out t he necessary success not ificat ions.

Risk s and I ssues t o Consider The following are early warning signs t hat t he proj ect m ight be going off t rack and is becom ing a high risk: ?

? ? ? ? ?

Tailored soft ware enhancem ent s ( as opposed t o m inor cust om izat ion of st andard feat ures) in t he schedule of deliverables Any request s from a supplier or vendor for clarificat ion, am endm ent s, or deviat ions St akeholders redefining any changes t o t he deliverables ( scope creep) An unforeseen requirem ent for any specialist skills or resources Changing schedules wit hout approval due t o frequent slippage on progress report s No possibilit y of revert ing t o t he "old" syst em in case of disast er

Delivering W hat W as Prom ised I t is im port ant t hat proj ect m anagers deliver what was prom ised t o t he client , adding value wherever required. A readiness review is t he form al t ransfer of inform at ion from t he syst em s developm ent t eam t o t he syst em t est t eam . This process is t o t ake place at t he end of each phase of t est ing. The purpose of a readiness review is t o com m unicat e clearly t he st at us of t he syst em prior t o t he st art of t he syst em t est . This is a crit ical st ep because it generat es awareness of t he following: ? ? ? ?

The st abilit y of each funct ion Various t est s t hat have been perform ed Out st anding defect s ( discussion of defect s should t ake place) More funct ionalit y t o be com plet ed during t he course of t est ing

Accept a nce Rea diness Review At t he end o f t he syst em t est phase, t he proj ect m anager should conduct a readiness review m eet ing. He or she m ust m eet wit h m anagem ent , client s, m em bers of t he accept ance t est t eam , and t he developm ent t eam t o assess result s of syst em t est ing and t he st at e of preparat ions for accept ance t est ing. The out put of t he review should ident ify and discuss any out st anding problem s t hat m ay im pose t echnical lim it s on t he t est ing or m ay affect schedules. The syst em t est and developm ent t eam s should be cert ain t hat t he syst em is com plet e and reliable before it is sent t o t he accept ance t est t eam . Test ers will be validat ing t hat business requirem ent s have been fulfilled and ensuring int egrat ion int o t he t arget environm ent , so an accurat e assessm ent of t he st at us is necessary. A basic agenda for t he readiness m eet ing would include t he following point s: ? ? ? ? ? ? ? ?

A walk t hrough of t he funct ionalit y t est ed An est im at ed t im e of com plet ion for any funct ionalit y t o be finished during t he next phase of t est ing A review of general design considerat ions A review of dat abase design and business rules Out st anding problem s t hat will not be fixed by t he st art of t est ing Out st anding problem s t hat will not be fixed in t he upcom ing product ion release Changes ( eit her addit ions or delet ions) in t he scope of t he release A review of t he current proj ect plan

LESSON S LEARN ED DURI N G PROJECT I M PLEM EN TATI ON "What could be sim pler t han buying som e com put ers, t hrowing t hem on a deskt op, plugging t hem in and t urning t hem on?" The quest ion is sim ple: The answer is m uch m ore com plex. Com plexit y is alm ost always underest im at ed unt il well aft er t he st art of t he planning process. Many of t he elem ent s of deploym ent require special coordinat ion and handling due t o t he lack of direct cont rol over t he processes or com pounding dependencies. Com plexit y can com e from the technical nat ure of a proj ect t hat at t em pt s t o t ake advant age of a new t echnology not yet t est ed by t he corporat ion and requires full int egrat ion int o t he exist ing syst em s. These fact ors don't surface unt il t he proj ect m anager dem ands act ion or som e form of change. I m plem ent ing a solut ion wit hout t est ing it properly is not accept able.

I W ish I Had Know n That Look for early warning signs t hat planned business benefit s will not be delivered. ? ?

? ?

? ?

?

?

? ?

I t is not clear t hat achieving t he business benefit s is t he t op priorit y of t hose m anaging t he proj ect . Tim e scales and resources for t raining, t est ing, and im plem ent at ion support have been eroded by proj ect slippage, and t here are proposals t o cut corners. Accept ance t est ing is being carried out by I S specialist s and t here is no involvem ent from t he business. Ot her part ies, who were not previously ident ified as part of t he proj ect , are now being ident ified as needing t o be involved in accept ance t est ing and im plem ent at ion. St aff involved in developing and agreeing t o t he original business obj ect ives have m oved on. The supplier has not dem onst rat ed t hat t he new syst em is com pat ible wit h exist ing syst em s and peripherals. The solut ion needs t o be t est ed and dem onst rat ed wit hin t he proposed environm ent ( including links t o exist ing syst em s) . Have t he t est s for accept ing t he syst em from t he supplier been planned and agreed upon? Has t he process for dat a conversion been planned and has sufficient t im e been allowed for it ? All necessary on-sit e preparat ions were not included in t he planning ( e.g., accom m odat ion, cabling, safet y, and securit y) . All dependencies, such as slippage on ot her relat ed proj ect s, have not been t aken int o account . Too lit t le at t ent ion is paid t o t est ing t he final solut ion.

Phase Com plet ion Checklist The proj ect m anager should ensure t hat t he following proj ect docum ent at ion is filed wit hin t he m ain proj ect folder in order t o com plet e t he proj ect im plem ent at ion phase: ? ? ? ?

Proj ect im plem entation plan Training plan and schedule Qualit y assurance plan Test cases and t est script s

? ? ? ? ?

Accept ance cert ificat e St at us report s Minut es of t he m eet ing Any inbound and out bound correspondence All final proj ect cost s, such as t im esheet s, invoices, and so fort h

Ch a pt e r 9 : Closin g t h e Pr oj e ct PROJECT CON CLUSI ON Oft en t he m ost neglect ed phase of any proj ect is t he closure phase. The closure phase brings t he proj ect t o an orderly conclusion for t he benefit of t he organizat ion and also for any fut ure proj ect . At t his st age, t he m aj orit y of proj ect m anagers are looking at or have already been assigned new proj ect s. I t is exact ly at t his point t hat m any proj ect m anagers begin neglect ing t he closure phase t asks of a proj ect . One of t he m ain reasons for t his is t hat t here are adm inist rat ive t asks t o com plet e during t his phase. However, it is im port ant t o rem em ber t hat t he client has paid for t he proj ect , and t he client det erm ines when t he proj ect is com plet e. So, rem em ber t o com plet e t he proj ect life cycle. I f t he proj ect does not receive t he proper support unt il t he very end, t he client loses t he benefit s of t he proj ect and t he proj ect m anager will m ost probably lose t he recognit ion. I n t oday's m arket , client sat isfact ion requires m ore t han j ust im plem ent ing a qualit y solut ion. When a proj ect is com plet ed but t he post - proj ect support is not properly planned for, disast er st rikes, leaving t he client disappoint ed. This chapt er not only shows how t o review and close a proj ect properly, but m ore int erest ingly, how t o build a st rong client relat ionship. So, when is an I T proj ect really closed? Table 9.1 illust rat es t he various fact ors indicat ing a proj ect com ing up for closure. Ta ble 9 .1 : Fact ors affect ing proj ect closure Fact or Authorized by A decision is m ade st at ing t hat goals have been m et .

Proj ect sponsor and st akeholders

No addit ional value can be added t o t he proj ect .

Proj ect m anager

Proj ect handed off t o operat ions ( business) .

Business m anager or client

All resources have been released and reassigned.

Proj ect m anager

Today, no organizat ion can afford t o t hrow away pot ent ial work t hat would benefit it s st rat egy. Client s depend upon proj ect m anagers being able t o com plet e proj ect s successfully. Proj ect m anagers should realize t hat t he proj ect im plem ent at ion phase does not , by default , im ply proj ect closure. The closure phase, in effect , im plies t hat t he pro j ect m anager is ready t o review t he proj ect , release t he resources t o t he organizat ion, and ensure t hat all docum ent at ion has been com plet ed and finalized.

I t is essent ial t hat organizat ions learn lessons from previous proj ect s. There are m any occasions where organizat ions require sim ilar proj ect s or t echnologies t o be rolled out , and t hen find out , t o t heir disappoint m ent , t hat t he previous proj ect docum ent at ion was not archived or m aint ained. This poor pract ice of not m aint aining a proj ect hist ory only wast es t im e. However, if t he previous proj ect docum ent at ion was archived and properly m aint ained ( e.g., on- line library, proj ect folder) , t his not only saves considerable rework for t he proj ect m anager, but it lays t he basic foundat ion for what m ay be ahead on t he proj ect . I n essence, a sound pract ice of archiving, m aint aining, and docum ent ing t he lessons learned on a proj ect gives t he proj ect m anager a head st art . A post im plem ent at ion proj ect review is designed and held t o est ablish t he ext ent t o which t he o rganizat ion has secured t he business benefit s t hey had desired. The review should include whet her t he proj ect has m et ( 1) business obj ect ives, ( 2) user expect at ions, and ( 3) t echnical requirem ent s. The proj ect is norm ally rolled out t o t he operat ional business environm ent , which will be responsible for using t he new syst em . Once t his has been achieved, it is cust om ary t o have som e form of celebrat ion or acknowledgem ent t o reward bot h proj ect st aff m em bers and key st akeholders. ADM I N I STRATI VE CLOSURE I n order t o com plet e t he proj ect closure phase ent irely, it is necessary t hat t he proj ect m anager com plet e all relat ed proj ect adm inist rat ion t hat was generat ed during t he st art of t he proj ect . This m ay be a cont ract ual docum ent t hat has not been obt ained or, wo rse yet, outstanding paym ent s t hat have not been finalized. Many proj ect m anagers do not pay sufficient at t ent ion t o t he adm inist rat ive aspect of t he proj ect as t hey oft en com e out of environm ent s where som eone else does t his work. I n m any proj ect s t oday, it is up t o t he proj ect m anager t o handle t he adm inist rat ive com ponent . Rem em ber t hat poor docum ent m anagem ent ( e.g., poor filing pract ices, unt raceable paperwork) will only creat e addit ional problem s. The following sect ion describes t he m inim um am ount of adm inist rat ion necessary t o prevent t hese t ypes of problem s from arising. Generat e final proj ect invoices. All out st anding t im e- sheet s need t o be subm it t ed t o t he client for approval in order for invoices t o be generat ed for paym ent . The reason being for t his is t hat m any resources such as consult ant s or vendors need final paym ent for cert ain equipm ent or services t hat were perform ed against t he proj ect . These cost s need t o be reviewed and processed before a proj ect is closed. The proj ect m anager should co nfirm t hat t he following have been reviewed and are correct :

? ? ? ?

The original cont ract value has been fully invoiced. Any addit ional invoices are generat ed and subm it t ed for proj ect scope changes. All t hird part ies suppliers and vendors have been paid as planned. Credit paym ent s have been generat ed where applicable ( e.g., penalt ies) .

Updat e t he proj ect folder. Most im port ant ly, t he proj ect m anager needs t o updat e t he proj ect folder wit h all approved cont ract ual docum ents before closing it off and sending it t o t he financial depart m ent or com pany archive for filing. The reason being is t hat t he folder m ay be needed in t he fut ure for audit ing purposes at t he end of t he financial year or for sat isfying any fut ure disput e or inquiry t hat m ay t ake place. The following cont ent st ruct ure is recom m ended: ? ? ? ? ? ? ? ? ? ?

The st at em ent of work ( SOW) Request for proposal ( RFP) The client order or let t er of int ent Official correspondence on t heir com pany let t erhead All invoices subm it t ed t o t he client All credit not es subm it t ed t o t he client Copies of t im e sheet s subm it t ed and approved Purchase orders generat ed on t he proj ect Subcont ract or invoices and receipt s for expenses Proj ect disbursem ent s m ade on t he proj ect ( e.g., st at ionary, t ravel, et c.)

Creat e t he proj ect review que st ionnaire. This needs t o be developed for t he client in order t o assess t he overall success of t he proj ect from t he client 's perspect ive. This can assist t he proj ect organizat ion in im proving or correct ing any areas t hat m ay need it —which m ay lead t o additional t raining or process im provem ent . Creat e t he proj ect closure report . I t is cust om ary t o generat e a professional report for com pany st akeholders on t he findings of t he client quest ionnaire. I t should cont ain at least t he following inform at ion: ? ? ? ? ? ? ? ?

An execut ive sum m ary A logical progression of t he proj ect—background, aim , and scope A brief descript ion of risks—t echnical, financial, or resource Recom m endat ions, if any Conclusions Acknowledgem ent s t hat m ay want t o be m ade Deliverable sign off Lessons learned—added t o t he proj ect reposit ory

? ?

Client sign off Client reference let t er

Offer proj ect recognit ion or rew ards. I n m any cases, it is cust om ary t o have a form al proj ect "Hanover" cerem ony or event , whereby st akeholders are rewarded or recognized. This m ay t ake t he form of special cert ificat es or flyers. These docum ent s need t o be coordinat ed ( anot her proj ect ! ) by t he proj ect m anager. The following are exam ples of official rewards: ? ? ?

Let t er of Achievem ent or Acknowledgem ent t o t he st akeholder. Cert ificat e of Friendship or Valued Relat ionship. A financial reward, in t he form of a gift , voucher, or check

Archiving Proj ect Docum ent at ion Because of t he com plexit y and t ypes of proj ect s encount ered, it is beneficial t o archive proj ect docum ent at ion and source code, in order t o allow ot her proj ect m anagers on fut ure proj ect s t o review and use t his archived m edia in a product ive m anner. This inform at ion can assist ot hers by elim inat ing previously encount ered problem s. New proj ect m anagers will be in t he posit ion t o leverage and develop ext ensions t o hist orical proj ect docum ent at ion wit h m inim al disrupt ion. I f t he sam e t eam is developing a sim ilar t ype of proj ect or solut ion, it is advisable t o keep t he docum ent at ion and lessons learned wit hin t hat specific proj ect t eam , and not m ove t he inform at ion elsewhere. However, if t he proj ect inform at ion is incorrect ly archived and im properly adm inist ered from a configurat ion or docum ent at ion m anagem ent perspect ive, t he following m ay occur: ? ? ?

The inform at ion could be m isplaced and cost valuable t im e being ret rieved. The inform at ion could be lost perm anent ly and hold no value t o fut ure proj ect s. Only cert ain archived inform at ion will be recovered.

Sim ilarly, if a proj ect closes and m uch t im e passes before anot her proj ect is considered, it is im port ant t o est ablish proper archive procedures so t hat t he fut ure proj ect t eam can pick up where t he last t eam st opped. I recom m end t hat a cent ralized docum ent at ion and configurat ion m anagem ent syst em be creat ed t o allow any fut ure proj ect t eam s t o ( 1) ident ify, ( 2) cont rol, ( 3) audit , and ( 4) account for hist orical proj ect inform at ion. This inform at ion would include

? ? ? ? ? ? ? ? ? ? ?

Developm ent source code Proj ect coding st andards Proj ect definit ion docum ent Proj ect chart er Technical specificat ions Qualit y assurance plans and t est script s Minut es of t he m eet ings Proj ect m anagem ent plan Master record index t hat list s all docum ent at ion placed under configurat ion cont rol Proj ect cont act list Proj ect not ebook

I t is im perat ive t hat som eone m akes and archives a perm anent backup of t he proj ect inform at ion. Once t he proj ect m anager has com plet ed t he "lessons learned" from t he proj ect , all proj ect inform at ion m ust be sent t o t he reposit ory ( eit her m anual or elect ronic based) for fut ure referencing. This proj ect archive reposit ory should be m anaged by a ( 1) proj ect office, ( 2) inform at ion syst em s configurat ion m anagem ent depart m ent , or ( 3) an adm inist rat ion depart m ent . Archived proj ect docum ent at ion should be classified and grouped by: ? ? ? ?

Proj ect t ype ( e.g., Web applicat ions/ CRM) Proj ect t echnology ( e.g., Oracle) Proj ect num ber ( e.g., Proj ect 12345) Financial year ( e.g., 2002, 2003)

Closure Checklist I have always found t hat a closure checklist serves a useful purpose because it provides a quick sum m ary of t hose proj ect it em s t hat m ay require com plet ion by t he proj ect m anager. I n order t o achieve a proper closure on t he proj ect , t he proj ect m anager should verify t hat t he following quest ions have been answered. ? ? ? ? ? ? ? ?

Have all t he proj ect obj ect ives been achieved? I s t he client sat isfied wit h t he overall proj ect ? Have t he necessary post - proj ect support agreem ent s been est ablished? What were t he m aj or concerns wit h t he proj ect ? What are t he key lessons learned from t he I T proj ect ? What would you do different ly? Do you feel t he solut ion was cost effect ive? When would it be applicable t o enhance or updat e t he delivered solut ion?

Early Proj ect Closure I t m ay happen at any st age during a proj ect t hat som eone m akes a decision t o close down t he proj ect before it is com plet e. That doesn't sound t oo healt hy, does it ? The reason for t his is m ost probably a culm inat ion of bad event s t hat lead t o t he proj ect being closed: Proj ect closure is rarely influenced by a single, random event alone. The decision t o close t he proj ect is a large undert aking in it self and is norm ally m ade by t he proj ect sponsor and t he execut ive t eam in t he organizat ion. Suffice it t o say, closing a proj ect early requires delicat e handling, as t he wrong approach will leave proj ect t eam m em bers disappoint ed and, in cert ain cases, leave t he organizat ion searching for ot her proj ect s. When closing down a proj ect , t he proj ect m anager should creat e a closure plan t hat nam es all t he necessary resources and act ion it em s t o rem ove and disassem ble t he proj ect . A separat e schedule will m ost likely be needed t o perform an early closure, and t he t im e scheduled t o com plet e t his should not be t aken light ly. Any financial im plicat ions of t he early clo sure of t he proj ect , such as penalt ies or losses, should be brought t o t he at t ent ion of t he execut ive t eam . Depending upon t he circum st ances of t he specific proj ect , it is wise not t o rush in and blam e individuals for t he overall failure of t he proj ect . I f t he case is t hat t he proj ect m anager failed t o m eet t he proj ect obj ect ives, a decision should be m ade early on t o replace t he proj ect m anager, not t o close t he proj ect . Com m unicat ing Proj ect Closure The cent ral point of cont act for proj ect closure is t he proj ect m anager, who ( hopefully) by t his t im e has proven his or her capabilit y as an effect ive com m unicat or. A proj ect m anager needs t o provide effect ive feedback t o ( 1) m anagem ent , ( 2) t he client , ( 3) users, and t he ( 4) proj ect office about t he progress o n t he final st eps t o com plet ion. This is accom plished by having a proj ect review m eet ing wit h t he proj ect office m anager or direct supervisor. I t is at t his st age t hat m anagem ent m ay present t he proj ect m anager wit h anot her proj ect or proj ect s or inform him or her of an im pending release. Addit ionally, t he proj ect m anager m ust also docum ent t he final proj ect progress on t he st at us report for t he proj ect file. The key here is t o cont inue t he com m unicat ion process unt il t he end of t he proj ect . Post - Proj ect Review A post- proj ect review m eet ing should be held soon aft er proj ect im plem ent at ion, allowing bot h t he client and t he proj ect m anager t o est ablish t he ext ent t o which t hey have secured t he business benefit s ant icipat ed and t o t ransfer any lessons learned ( bot h posit ive and negat ive) back t o fut ure proj ect s. The proj ect m anager calls t his post -

proj ect review m eet ing and includes at t endees represent ing t he areas t hat are present ed in Table 9.2 . Ta ble 9 .2 : Post - proj ect review st aff Required At t endees

Opt iona l At t endees

I S proj ect m anager

Proj ect sponsor

Business proj ect m anager

Analyst s, m arket ing, t raining

Client

Users, invest ors

Developm ent m anager

DBA, syst em adm inist rat or, developers

Soft ware t est ing m anager

Test ers

Qualit y assurance m anager

QA st aff

Operat ions m anager

Help desk, I T support

Scheduling a post - proj ect review m eet ing is oft en difficult ; however, t he proj ect m anager should announce t he t im e well in advance and request all required t eam m em bers at t end. The proj ect m anager, when considering what t o discus, should draw up a basic agenda and dist ribut e it well in advance of t he act ual m eet ing. I n part icular, t he post - proj ect review m eet ing should seek t o underst and and docum ent t he following: ? ? ? ? ? ? ?

Overall proj ect st at us and highlight s What t he proj ect risks were Lessons learned Reasons for cost overruns or cost savings Reasons for being behind schedule or ahead of schedule Scope creep and change cont rol Resource ut ilizat ion on t he proj ect

Reviews should be undert aken in a const ruct ive and open m anner wit h t he aim of im proving fut ure proj ect perform ance. St aff Reskilling I nvest m ent in st aff developm ent is fundam ent al for any proj ect 's success. I t is a known fact t hat inform at ion t echnology changes very rapidly ( t echnologies from even t hree or five years ago m ay be inappropriat e now) , and on a large- sized proj ect , individuals wit h out dat ed skills face a difficult t im e being select ed on proj ect s t hat require t he lat est skillset s. An exam ple of t his problem was t ransit ioning from m ainfram e proj ect s t o w eb- based proj ect s. Mainfram e resources had t o learn web- based skills quickly in order t o secure work on fut ure proj ect s. The proj ect m anager,

t herefore, has an obligat ion t o ensure t hat individuals have been t rained in newer t echnologies in order t o keep pace wit h t oday's global econom y and t im e pressures. An em phasis on m ore form al and int ense I T courses allows individuals t o increase t heir learning pace and broaden t heir sources of inform at ion. The next proj ect m ay very well be a proj ect where t rained individuals are able t o assist . RELEASI N G PROJECT RESOURCES Once proj ect st aff m em bers have finalized t heir respect ive t asks, t hey are t o be syst em at ically released back t o t he proj ect "resource pool/ consult ing bench." I n m any cases, if t he individual has im pressed a client wit h fant ast ic t echnical skills, he or she probably will not be released. I nstead, he or she will probably cont inue working wit h t he client and be assigned a second proj ect . Therefore, proj ect m anagers should release t heir proj ect st aff in an orderly m anner and provide individuals wit h advance feedback as t o t heir next proj ect or what t he client is int ending t o do wit h t hem in t he short t erm . I f t he individual is t o rem ain wit h t he client , t he proj ect m anager should facilit at e his or her reut ilizat ion on ot her proj ect s as soon as possible, if t his is t he int ended plan. I f t he plan is not t o use t his person again, he or she is released back t o t he proper organizat ion. I t is com m on pract ice t hat when individuals com e off assignm ent and are released back t o t heir organizat ions, t hey cont inue t o book addit ional t im e t o t he proj ect , and t he proj ect m anager should com m unicat e t his fact t o all individuals being released. I f t his sit uat ion is left uncont rolled, t he proj ect m anager m ay face addit ional adm inist rat ion from t he financial depart m ent , as t he proj ect m ay be billed for t im e not act ually w orked. There are som e definit e advant ages and disadvant ages for t hose proj ect organizat ions t hat release and draw t heir t echnical resources from a com m on t echnical pool ( see Table 9.3 ) . I f t he proj ect m anager is releasing resources back t o t he resource pool, he or she should com m unicat e t his t o t he resource pool m anager, who will st art advert ising t he individuals' skills and capabilit ies. Table 9 .3 : Sharing a com m on resource pool Adva nt a ge s

Disadvant ages

Cent ralized resource pool

Best resources always on assignm ent

Abilit y t o select t echnical resources

Rem aining resources m ay be unsuitable

No ext ernal hiring necessary if resource is available

Underut ilized resources

M AI N TEN AN CE AN D SUPPORT Once t he proj ect has been put t hrough t he accept ance t est ing t rials, t he syst em becom es t he responsibilit y of t he inform at ion syst em s support group eit her wit hin t he organizat ion or wit hin t he com pany providing the support funct ion for t he organizat ion. Support cost s are not im m ediat ely visible t o t he client , and t his is oft en where problem s em erge. Client s will never be able t o recover any syst em if t he proper support infrast ruct ure has not been put int o place. As an analogy for proj ect support , I offer t his exam ple: The Brooklyn Bridge, long a sym bol of "form m eet ing funct ion," was an engineering m arvel when it was const ruct ed in 1884. Since t hen, t his st ruct ure has undergone close t o sixt y m aj or m ain t enance inspect ions and has been undergoing renovat ions since 1980—proving t hat even t he soundest and m ost advanced designs need ongoing support . Whet her it is const ruct ion or inform at ion t echnology, m aint enance and support of syst em s need t o be catered fo r and included int o t he life cycle for t he client t o review. Client s and proj ect m anagers need t o be aware of t he full cost of t he proj ect life cycle once it is com plet e. Support aft er Proj ect Closure So oft en, proj ect s are com plet ed wit hin t im e, specificat ion, and cost and are form ally signed off as successful proj ect ( s) , but t hen fail dram at ically wit hin t he com ing few weeks and m ont hs, as a result of inadequat e support being available for t he im plem ent ed syst em . Support can vary from solut ion t o solut ion and really depends upon t he com plexit y of t he archit ect ure being deployed. I have oft en seen solut ions being handed over t o client s who are so j oyful at receiving t he solut ion but who are ignorant about t he full requirem ent s and levels of support needed t o m aint ain t he solut ion. The proj ect m anager should cont em plat e t he following quest ions when considering support and m aint enance for a solut ion: ?

? ? ? ?

Has t he proj ect m anager involved t he necessary I S support st aff from t he proj ect st art and has he or she m ade t hese st aff aware of t he archit ect ure t hey are t o m aintain? Does the vendor offer 24× 7× 365 support and are the rat es accept able t o t he client? Are t he approved SLAs developed and in place for each separat e hardware and soft ware it em ? Have t he necessary soft ware license fees per soft ware seat been budget ed for an annual basis? Have t he necessary hardware spares and accessories ( which have a short life cycle) been ordered and placed

? ? ?

?

int o t he st ore? Does t he necessary hardware capacit y and st orage exist for fut ure expansion of t he syst em ? Has sufficient bandwidt h been allocat ed t o handle calculat ed volum es of an int ended solut ion? Has t he I S support st aff been t rained in support ing t he t echnology and are t hey able t o resolve t echnical issues or able t o cont act t he t hird- part y suppliers for det ail support ? Has t he help desk st aff been t rained t o ident ify and log calls from users of t he solut ion?

Act ivat ing Help Desk Support As proper cust om er relat ionships need t o be m anaged during and aft er t he proj ect , it becom es necessary t o ensure t hat t he client I T help desk st aff have been inform ed and have received t he fo llowing aspect s of t he proj ect , before closing off t he proj ect : ?

?

?

?

?

The proj ect m anager has not ified t he help desk of t he new solut ion, which is being accept ed by t he relevant business funct ion ( e.g., finance depart m ent ) . The help desk num ber is clearly displayed on t he relevant applicat ion or specific web sit e, w hich users can cont act . The help desk has received an updat ed cont act list of det ails of t he relevant int ernal st aff, suppliers, and cont ract ors who support t he solut ion in any event of downt im e or failure. The necessary operat ional support st aff has been t rained t o t he appropriat e level of support t o correct any t echnical problem s t hat arise. The proj ect m anager has provided t he help desk wit h a script of possible problem s t hat users of t he new solut ion could encount er.

Service Level Agreem ents The proj ect m anager and t he operat ional support represent at ive need t o ensure t hat a form al service level agreem ent is developed and put int o effect bet ween t he organizat ion and suppliers, t o m aint ain cont inued support and service. Fut ure Upgrades and Enha nce m e nt s I sn't it ironic t hat t he m om ent a proj ect has been im plem ent ed, a m agical list of enhancem ent s and upgrades are wait ing t o be m ade t o t he proj ect ?

Proj ect m anagers should ant icipat e t hat t he t echnology used on t he im plem ent ed solut ion has a lim it ed syst em life before it becom es out dat ed and t hus requires enhancem ent s or upgrades. I n order t o prepare for t his event ualit y, proj ect m anagers should est im at e when t he next likely change will occur. They should forward t hese enhancem ent s or upgrade cost s and schedules t o t he operat ions m anager or execut ive t eam s who are t aking ownership of t he live syst em . These forecast ed cost s should be placed on t he m edium - t o long-t erm radar screen so as t o assist wit h t heir budget ing and planning. Proj ect Celebrations I f t he proj ect was successful, t he proj ect m anager should hold a celebrat ion for t he proj ect t eam . A celebrat ion provides an excellent opport unit y for t he ( a) proj ect sponsor, ( b) client , or ( c) proj ect m anager t o acknowledge specific individuals or t eam cont ribut ions, as well as present awards t hat m ay have been earned during t he life of a proj ect . A celebrat ion brings closure t o t he proj ect for all t eam m em bers, and it serves as a m ot ivat ion for t he next proj ect . I n m y experience, it is com m on t o hand out proj ect souvenirs or gift s t o t hose m em bers who achieved success. Proj ect M a na gem ent Foreca st I n closing t his chapt er, I t hought it m ost appropriat e t o forecast int o t he near fut ure and envision t he role t hat t he I T proj ect m anager of t om orrow m ust play. I nform at ion t echnology proj ect s are used in virt ually every indust ry vert ical t oday and will dram at ically increase over t he next few years, m aking rem arkable achievem ent s and st rides in all indust ries. Yet , t he phenom enon of inform at ion overload is in it s infancy. By best account s and predict ions, if t he am ount of inform at ion doubles every eight een m ont hs, t hen by 2010 t here will be roughly 700 bit s of dat a for every fact in exist ence. This does not necessarily im ply t hat we will be bet t er inform ed. As I T proj ect m anagers, we will need t o m anage proj ect s whereby m eaningful fact s—t hose t hat are useful and reliable—are put int o place and t hen ensure t hat t his inform at ion becom es a valuable resource. Addit ionally, I T syst em s will also becom e far m ore powerful, intelligent, and flexible t han ever before. I m port ant changes will t ake place wit h such increasing frequency t hat it will becom e vit al t o m anage t he developm ent and delivery of such solut ions correct ly. We will see rapid advances in t he fields of ( 1) int egrat ed web solut ions, ( 2) t elecom m unicat ions, ( 3) highspeed net works, ( 4) m edical- based t echnologies, and ( 5) inform at ion engineering. These solut ions m ay very well dict at e t hat indust ries require new processes, int egrat ion, and funct ionalit y overnig ht . These are t he t ypes of challenges I T proj ect m anagers will face in t he near fut ure.

Let m e exam ine one of t hese vert icals in closer det ail. Proj ect s in t he m edical and pharm aceut ical indust ries will use an ever- increasing am ount of inform at ion t echnolo gy t o assist in ident ifying, diagnosing, and solving m edical illnesses. I T solut ions ranging from noninvasive ult rasound applicat ions all t he way t o advanced applicat ions, which provide im proved clinical capabilit ies, will be developed by high- t ech organiz at ions t o assist m edical pract it ioners in t heir daily t asks. These solut ions will focus on ut ilizing super- fast dat abases and analyt ical t ools t hat can increase diagnost ics t echniques for st udying m edical dat a and can allow for t his com plex dat a t o be m odeled and used t o t reat pat ient s. Toget her wit h t he pioneers and visionaries out t here, proj ect m anagers will st ill rem ain t he key enablers in designing, developing, and delivering a new generat ion of applicat ions and t echnologies t o client s on a global basis. The Hum an Genom e Proj ect is one of t hese kinds of proj ect s. I t applies t he lat est t echnology t o shed light on how fault y genes play a role in disease causat ion. The proj ect , which began in 1990, was originally scheduled t o last fift een years, but it was com plet ed way ahead of schedule, prim arily due t o t he rapid advances m ade in inform at ion t echnology. The principles and applicat ion of sound proj ect m anagem ent were key in bringing t his proj ect wit hin schedule. I nt erest ingly enough, t he t echnology obj ect ives est ablished at t hat t im e were t o: ? ? ? ? ?

I dent ify all t he 100,000 genes in hum an DNA Det erm ine t he sequences of t he 3 billion chem ical base pairs t hat m ake up hum an DNA St ore t his inform at ion in dat abases Develop t ools for dat a analysis Transfer relat ed t echnologies t o t he privat e sect or

I W I SH I H AD KN OW N TH AT I t is t he proj ect m anager's secondary t ask, while working wit h t he client sit e, t o seek out and obt ain repeat business where possible. Many opport unit ies are m issed due t o t he fact t hat t he proj ect m anager is eager t o m ove ont o ot her im port ant client s in order t o furt her his or her career and is not sat isfied by rem aining wit h a single client all t he t im e. I n doing t his, t he proj ect m anager loses valuable opport unit ies. I t is a com m on m isconcept ion t hat proj ect closure is left unt il t he very end in t he proj ect life cycle. I n fact , it is cat ered for during t he init ial planning phase while t he proj ect m anager is planning t he ent ire proj ect . Be wary of t hose I T proj ect s t hat are no t form ally closed and t end t o drift and becom e subproj ect s. I t is com m on for m any organizat ions t o sim ply ext end t he original proj ect int o yet anot her proj ect where t he init ial "bugs" or t rouble t icket s can be resolved. I n such a scenario, proj ect m em bers will easily becom e disheart ened and will want t o m ove ont o

som et hing else. I t is t he proj ect m anager's j ob t o ensure t hat t he proj ect is form ally com plet ed. Phase Com plet ion Checklist The proj ect m anager should ensure t hat t he following proj ect issues and docum ent at ion are com plet ed and filed wit hin t he m ain proj ect folder ( e.g., m anual or elect ronic) in order t o com plet e t he proj ect closure phase: ? ? ? ? ? ? ? ? ?

Proj ect closure report Com plet ed client quest ionnaire survey Proj ect acknowledgem ent s Final m inut es of t he m eet ing Any inbound and out bound correspondence All final proj ect cost s, such as t im e sheet s and invoices ( which should have been paid or collect ed) Final financial report Final t echnical report , including any pat ent ( s) filed for during t he proj ect life cycle I nvent ory report of all proj ect equipm ent —either leased or bought

Glossa r y A- C Account abilit y. What a person can be count ed on t o do. That person will be called t o account if t he proj ect he or she is account able for is not achieved or does not m eet t he required st andards. Act ivit y. A cohesive unit of work, t he opt im um level of reference for planning and com m unicat ion. Archit ect ure. The soft ware archit ect ure includes t he dat a m odel st ruct ure, user int erfaces, workflow, and int eract ions of t he various com ponent s. I t is t he blueprint for t he design of t he soft ware proj ect . Bar chart . A graphical represent at ion of act ivit ies wit hin a proj ect over t im e. The durat ion of each act ivit y is shown as t he bar, t he ends of which correspond t o t he st art and end dat es of t he act ivit y. A bar chart is also known as a Gant t chart . Baseline. An elem ent of t he business case for a proj ect describing cost s and perform ance levels t hat would be achieved if t hose operat ions cont inued unchanged over t he planned period of t he proj ect . The baseline is used t o com pare t he cost s and benefit s of t he opt ions evaluat ed in t he business case. Business a na lyst . An individual who perform s t he business assessm ent s and im provem ent s t o an organizat ion's product s or syst em s. Business case. The sect ion of t he proj ect definit ion st at em ent t hat provides t he j ust ificat ion for t he com m it m ent of resources t o a proj ect . The business case should dem onst rat e t hat t he m ost cost- effect ive com binat ion of proj ect s has been select ed when com pared wit h cost alt ernat ives. I t also

provides t he wider cont ext and j ust ificat ion for infrast ruct ure invest m ent and cost s of im plem ent ing policies and st andards. Business operat ions. A grouping of one or m ore business processes t hat com bine t o achieve a prim ary goal of t he organizat ion ( for securit y benefit ) . CCB. See Change cont rol board.. Change cont rol. A form al process t hrough which t he changes t o t he proj ect are int roduced and approved. Cha nge cont rol boa rd. St eering com m it t ee est ablished in order t o approve or rej ect proposed changes t o a syst em or product . The CCB m ay require furt her assessm ent s and feasibilit y before m aking a decision. Cha nge request . A process t hat det ails a proposed change, evaluat es t he change, m akes a decision t o approve or rej ect . Closure. Form al end t o t he proj ect , eit her because it is com plet ed or because it has been prem at urely ended. Com m unicat ions plan. The plan for how t he obj ect ives, plans, and progress of t he proj ect are t o be com m unicat ed t o st aff in order t o prom ot e a feeling of com m on ownership, t o facilit at e knowledge t ransfer and t raining, and t o ensure t hat t hose st aff are involved t hroughout t he life of t he proj ect . Concept phase. The second phase of proj ect m anagem ent . A feasibilit y st udy is conduct ed t o explore opt ions for realizing t he benefit s fram ework described in t he Program Brief. The program is fully defined, a benefit s m anagem ent regim e est ablished, and funding approval for m aj or proj ect s is obt ained. I nit ial Proj ect Briefs are writ t en t hat specify proj ect deliverables and out line proj ect plans. The result s of t he phase are docum ent ed in a Program Definit ion St at em ent .

Configurat ion m anagem ent . Approach t o ident ifying, cont rolling, and audit ing all syst em it em s t hat m ay be affect ed by fit , form , or funct ion. Cont ra ct . A m ut ually binding agreem ent t hat obligat es t he supplier t o provide specified product s and services t o t he buyer, who m ust pay for t hem . Correct ive a ct ion. Act ions t aken, upon evaluat ion of gaps bet ween perform ance and plan, t o rem edy t he gaps and put t he proj ect back on t rack t o deliver. Cost Benefit Analysis. A proj ect t echnique for com paring t he cost s of t aking a part icular course of act ion wit h t he benefit s achievable from t he out co m e. Cost cont rol. The cont rolling of all changes t o t he proj ect budget and it s re- forecast ing. Cost m onit oring. The t racking of t he cost s spent t o dat e on t he proj ect and forecast ing t he cost s likely t o spend. Cost variance. The cost difference of proj ect act ivit ies. The variance can eit her be posit ive or negat ive. Crit ica l pa t h. The sequence of proj ect act ivit ies t hat det erm ines t he earliest com plet ion t im e for t he overall proj ect . D- I Dea dline. The final dat e or com plet ion dat e for a specif ic act ivit y or m ilest one. Delivera bles.

The specific out put s t hat t he proj ect seeks t o deliver. They are t angible benefit s t hat people can see. Each key deliverable is defined as a m ilest one on t he proj ect plan. Dependency. Proj ect act ivit ies t hat are linked or connect ed t o ot her proj ect t asks. One t ask cannot be com plet ed or st art ed unt il t he ot her has been st art ed or com plet ed. Design a ut horit y. A role wit hin t he proj ect t hat has t he responsibilit y t o m anage t he design of t he business and inform at ion syst em s t hat are affect ed or creat ed by t he proj ect . This m eans ensuring t hat designs are consist ent across all proj ect s in t he port folio and consist ent wit h support ing services and infrast ruct ure designs and plans, and t hat designs com ply wit h t he policies and st andards of t he organizat ion and t he proj ect . The design aut horit y is also responsible for change cont rol t o t echnical specificat ions and t echnical infrast ruct ure. Developm ent plan. A form al plan describing t he det ails of t he soft ware developm ent on t he pr oj ect . Durat ion. The t ot al period of t im e from t he st art up of an act ivit y t o it s com plet ion. This period of t im e t ypically consist s of t he t im e required t o m ove t he work t o com plet ion. Earned Value. A perform ance- based m anagem ent syst em for est ablishing baseline cost , schedule, and perform ance goals for a capit al proj ect and m easuring progress against t hese goals. Effort . The act ual t im e required t o com plet e a proj ect act ivit y. Est im a t e. An analysis or forecast of t he proposed act ivit ies, effort s, and resources t o be ut ilized on a proj ect . Fe a sibilit y a sse ssm e nt .

During t he Proj ect Definit ion phase, t he proj ect feasibilit y st udy is conduct ed t o develop in furt her det ail t he business requirem ent s and benefits analysis contained in t he Proj ect Brief in order t o draw up t he blueprint of t he fut ure business operat ions and t o scope and st ruct ure im plem ent at ion opt ions. Ga nt t cha rt . Sim ple t echnique for displaying t he schedule of act ivit ies or t asks against a t im e line and ident ifying t he crit ical pat h wit hin a proj ect . Go / N o Go Decision. A form al decision t hat is m ade by a com m it t ee or execut ive t o com m ence wit h or cancel t he proj ect . Goal. The desired end result . I t can be defined as a specific m easurable accom plishm ent t o be achieved wit hin a specified t im e and cost const raint . I dent ificat ion phase. The first phase of proj ect m anagem ent , in which all high- level change proposals from available st rat egies and init iat ives are considered collect ively and t heir obj ect ives and direct ions t ranslat ed int o one or m ore achievable proj ect s of work. For each proj ect ident ified, a Proj ect Brief is writ t en and a proj ect direct or appoint ed. I m plem ent at ion plan. A plan describing how t he proj ect is going t o deliver and approach t he im plem ent at ion of t he proposed changes. I m plem ent a t ion st ra t egy. The overall approach t o be used in im plem ent ing a change int o t he business or m arket . I nform at ion t echnology. Electronic- based com put er syst em s, appliances, and soft ware. I nfrast ruct ure. I n t his guide, infrast ruct ure is broadly defined t o include bot h "t radit ional" form s of infrast ruct ure such as I S/ I T, t elecom m unicat ions, and est at es, as well as support ing services such as account ancy, st affing, and personnel.

I ssu e s. Those specific it em s t hat have occurred and m ay t hreat en t he success of t he proj ect . I ssue log. A record of all issues relevant t o t he proj ect t hat , if left unresolved, could have a negat ive effect on t he proj ect . I T. See I nform at ion t echnology.. K- P Kick - off m eet ing. An init ial m eet ing held wit h proj ect st akeholders t o discuss and present proj ect goals, scope, and responsibilit ies. Life cycle. A sequence of defined phases over t he full durat ion of a proj ect . Each phase has specific charact erist ics and each form s part of a logical sequence in which t he deliverables are defined and creat ed. Linea r responsibilit y cha rt . A t echnique used t o ident ify, isolat e, and docum ent various roles and responsibilit ies wit hin a proj ect or program . M et hodology. A process est ablished t hat can be adhered t o in order t o m eet obj ect ives. Milest one. This specifies t he result s or condit ion t hat a proj ect m ust occupy at a part icular point in t im e in order for t he proj ect t o rem ain on t rack t o achieve t he proj ect goal. Milest one plan. A sum m ary of t he proj ect m ilest ones and corresponding dat es. M onit oring.

This involves t he process of capt uring, assessing, and report ing on proj ect perform ance as com pared against t he plan. NPV. See Net present value.. N et present value. A t echnique based upon t he principle t hat a given sum of m oney is wort h m ore t oday t han in lat er years. Allows proj ect m anager t o reduce all values, bot h cost s and benefit s, t o a single sum expressed in t oday's m oney. N et w ork diagram . Schem atic display of t he proj ect 's act ivit ies and t he logical relat ionship ( dependencies) bet ween t hem . Also referred t o as t he Arrow Diagram m ing Met hod ( ADM) as each arrow represent s an act ivit y. Pha se. A part of t he proj ect 's life cycle, int o which act ivit ies t o m anage t he proj ect are grouped. The m ain phases of t he proj ect are Concept , Planning, Execut ion, Cont rol and Closure. Proj ect s I n Cont rolled Environm ent s ( t he CCTAs st andard m et hodology now called PRI NCE 2) is used for proj ect m anagem ent by m any governm ent and large, privat e- sect or I T depart m ent s. Now designed t o m ake t he m et hod m ore suit able for sm aller and non- I T proj ect s. Procurem ent pla n. Form al plans list ing t he resources t hat need t o be purchased for t he proj ect . Pr oj e ct . A single, t em porary set of act ivit ies bounded by a business obj ect ive. The proj ect includes t he cont rolled environm ent of m anagem ent responsibilit ies, act ivit ies, docum ent at ion, and m onit oring arrangem ent s by which t he port folio of proj ect s achieves it s goals and t he broader goals of t he program . Proj ect definit ion. The agreed st at em ent of obj ect ives and plans bet ween t he t arget business operat ion, t he proj ect direct or, and t he senior m anagem ent group ( m anagem ent board, st eering com m it t ee) t o whom t he Proj ect Direct or is

report ing. This form s t he basis for funding t he proj ect and is t he key m onit oring and cont rol docum ent . I t is a dynam ic docum ent , m aint ained t hroughout t he life of t he proj ect . Proj ect direct or. The senior m anger wit h individual responsibilit y for t he overall success of t he proj ect . This person is drawn from t he m anagem ent of t he t arget business area. Proj ect execut ion phase. The t hird phase of proj ect m anagem ent , in which t he proj ect port folio m anagem ent and t ransit ion act ivit ies are undert aken. Com pliance wit h t he proj ect design, corporat e and proj ect policies, st andards, and infrast ruct ure plans is m onit ored and assured. Proj ect folder. A collect ion and cat egorizat ion of key proj ect docum ent at ion accessible t o proj ect st akeholders during and aft er t he life of a proj ect . A hardcopy file or elect ronic folder is m aint ained. Proj ect m anagem ent plan. The approved working m ast er docum ent used on a regular basis by t he proj ect m anager and his or her t eam t o ident ify, m onit or, and t rack t he developm ent of t he proj ect . Proj ect m anager. The appoint ed person who is responsible for t he day- to - day m anagem ent of t he proj ect , on behalf of t he organizat ion. Proj ect office. See Proj ect support office.. Proj ect review . A form al review of t he proj ect at a cert ain point in t im e. Det erm ines t he progress m ade, risks, issues, and general t rends. Can be held at each phase of t he proj ect . Proj ect support office. An organizat ion rendering t he necessary adm inist rat ion t o t he proj ect m anager, part icularly wit h m anagem ent inform at ion report ing. This office

m ay, where appropriat e, serve bot h t he program and t he individual proj ect s. Proj ect t e m pla t e s. A series of st andardized elect ronic or hardcopy form at s used on t he proj ect . Prot ot yping. The developm ent of a product or solut ion t hrough t he creat ion of rough m ock- ups, which t hrough t rial and error, get increasingly closer t o t he desired end result . Q- S QA. See Qualit y assurance.. Qualit y assurance. The planning, design, work, and procedures necessary t o ensure t hat t he necessary qualit y is achieved. Qualit y cont rol. The inspect ion of finished product s t o ensure t hat t hey m eet t he required st andards or are fit for t heir purpose. Qualit y plan. A com ponent of t he Program Definit ion St at em ent t hat set s out quality obj ect ives for t he program 's design and execut ion, for t he fut ure business as described in t he blueprint , and for m anaging t hird part ies involved in t he pr oj ect . RAD . See Rapid applicat ion developm ent .. Rapid applicat ion developm ent . A t echnique used t o facilit at e and increase t he developm ent of an applicat ion. Request for proposal.

Used as a bid docum ent t o solicit proposals from suppliers in a form at t hat facilit at es com parison and ensures sufficient clarit y on what is being request ed. Resource plan. A com ponent of t he proj ect definit ion st at em ent t hat addresses how t he proj ect will be resourced and specifies what support ing services, infrast ruct ure, and t hird part y services are required. Resource pool. A list of resources available for assignm ent t o a t ask or group of t asks for m ult iple proj ect s. Ret urn on invest m ent . Form al t echnique used t o calculat e t he proj ect 's financial ret urn based upon t he init ial invest m ent . RFP. See Request for proposal. . Risk. Any pot ent ial t hreat or occurrence t hat m ay prevent t he proj ect from being successful. A risk is an event t hat m ay happen. Risk plan. A com ponent of t he proj ect definit ion st at em ent t hat cont ains a record of all risks in t he proj ect environm ent . I t assesses possible im pact and describes what is t o do ( and when) t o avoid, rem ove, and cont rol risks. I t includes t he det ailed processes for m anaging t he risk. ROI . See Ret urn on invest m ent .. Schedule. A t im eline t hat shows when a proj ect is t o be com plet ed. Schedule variance. The calculat ed schedule difference indicat ing whet her t he schedule is ahead or behind schedule.

Scope. Est ablishes t he boundaries wit hin which t he proj ect will work and helps define t he areas it will effect . Service level a greem ent . A cont ract ual docum ent det ailing t he level of work and t he work schedule t o be perform ed by t he vendor. The SOW becom es part of t he event ual cont ract bet ween t he vendor and t he organizat ion. SLA. See Service level agreem ent .. SM E. See Subj ect m at t er expert .. SOW . See St at em ent of work.. Sponsor. Person account able t o t he business for t he achievem ent of t he proj ect goals and benefit s. The sponsor achieves t his t hrough t he proj ect m anager and proj ect t eam . St akeholder. Anyone who has, or believes he or she m ay have, t he right t o be involved in t he proj ect . St akeholders are affect ed by t he proj ect ; t hey are eit her int erest ed in t he progress of t he proj ect or are t he act ual users of t he proposed solut ion. St at em ent of w ork . A form al docum ent creat ed by an organizat ion in response t o an RFP t hat describes t he t asks t o be com plet ed in sufficient det ail. St a t us r e por t . Proj ect progress, variance, and correct ive act ions are sum m arized by proj ect m angers in brief st at us report s. These are co llat ed by a proj ect office int o a proj ect progress report , which is issued prior t o each Proj ect Execut ive m eet ing. St at us report s should cover forecast s of problem areas as well as overall proj ect perform ance.

St eering com m it t ee. A body est ablished t o m onit or t he proj ect and t o assist t he sponsor and proj ect m anager in overseeing t he proj ect and delivering t he benefit s. St r a t e gy. A form al plan indicat ing t he course of act ion t o be undert aken t o m aint ain a com pet it ive edge. Subj ect m a t t er ex pert . An individual having specialist knowledge in t hose areas required by t he pr oj ect . Supplier. An organizat ion rendering a service or product s t o t he proj ect in support of m eet ing t he proj ect goal SW OT. An analyt ical t echnique t o help develop a plan based upon different int ernal and ext ernal fact ors for an organizat ion or m arket place. Known as St rengt h, Weakness, Opport unit ies, and Threat s analysis. Syst e m s a na lyst . An individual who perform s a t echnical assessm ent and analysis t o an organizat ion's product s or syst em s. T- W Ta sk . The sm allest indivisible part of an act ivit y t hat is needed t o t rack a proj ect . Te a m . A group of people who need t o achieve com plex t asks and m ut ual goals t hat require creat ivit y and int erdependent work t o succeed. U RS. See User requirem ent s st at em ent .. User requirem ent s st a t em ent .

A form al proj ect docum ent det ailing t he exact client requirem ent s dem anded for t he proj ect . W ork breakdow n st ruct ure. A t echnique t hat provides a logical form at for organizing all t he work required t o deliver a proj ect . Visually, t he work breakdown st ruct ure can be com pared t o an organizat ional chart . The first layer is t he proj ect goal, t he second layer is t he m ilest ones, t he t hird layer is act ivit ies, and t he fourt h layer is t asks. W BS. See Work breakdown st ruct ure..

I ndex N um ber 0 –100 rule, 2 2 1–223 A Accept ance: checklist , 3 4 testing, 1 9 9– 201 Account abilit y, defined, 2 8 1 Activity, 2 8 1 Agenda, 1 8 5 Analysis: diagram of, 126 issues addressed in, 8 7 kick- off m eet ing, 1 2 4 diagram of, 125 overview of, 85 t asks of, 87– 89 t echniques for I T proj ect , 97 –106 Arrow net work diagram t echnique: overview of, 144–145 sam ple, 145 Archit ect ure, 2 8 1 Assessm ent, 8 7 . See also Analysis

B Bar chart , 1 4 0–143 , 281 Baseline, defined, 2 8 1 Benefit - cost analysis ( BCA) , 112–114 Bill of m at erials ( BOM) , Product Breakdown St ruct ure and, 137 Bot t om - up est im at ion, 151 Budget : overv iew of, 158 sam ple, 159 , 203 working wit h, 2 0 2– 204 Business analyst : defined, 2 8 1 role of in proj ect analysis, 9 1 –9 2 Business case: defined, 2 8 2 diagram of, 108 overview of, 107–108 Business docum ent at ion, developm ent of, 106

Business im pact analysis: diagram of, 103 o verview of, 102–103 Business obj ect ives, 21 Business operat ions, defined, 2 8 2 C Celebrat ions, 276 Change control: defined, 2 8 2 overview of, 229–234 process of, 230–231 Change cont rol board ( CCB) : defined, 2 8 2 frequency checklist and, 2 2 5 responsibilit ies of, 33 , 232 Change request , defined, 282 Chart er, 1 6–1 7 originat ion of, 1 8 vs. proj ect plan, 1 6 Chief execut ive officer ( CEO) : roles of, 12 in st rat egic plan, 2 2 Chief finance officer ( CFO) , in st rat egic plan, 2 2 Chief inform at ion officer ( CI O) , roles of, 12 Client archit ect ure, analysis of, 1 0 3–106 Closure: adm inist rat ive, 2 6 3–272 checklist for, 268 com m unicat ion during, 2 6 9– 270 defined, 2 8 2 early, 2 6 9 fact ors affect ing, 2 6 2 overview of, 261–263 phase of, 60 report , 265 support aft er, 274–275 Com m ercial off- the- shelf solut ions ( COTS) , 115 , 118–119 Com m unicat ion: im port ance of, 17 –18 plan, 1 6 6 , 282 Com put er Based Training ( CBT) , 8 1 Concept phase: defined, 2 8 3 overview of, 58 –59 Configurat ion m anagem ent : baseline, 8 1

change cont rol and, 2 2 9–232 defined, 2 8 3 diagram of, 8 2 overview of, 80 –83 , 205– 207 t able of, 8 3 Conflict , 2 3 3–234 Consult ant : proj ect m anager as, 4 6 role of in proj ect analysis, 9 2 –9 3 Cont ingency plan, 1 6 3– 165 Cont ract , defined, 2 8 2 Control: conflict and, 2 3 3 –235 issues t o m onit or, 226 key areas of, 212 –216 overview of, 209–212 Correct ive act ion, 283 Cost : cont rol of, 215–216 , 218 , 283 defined, 1 1 2 diagram of, 160 m odels of, 159 –161 m onitoring, 2 8 3 variance, 2 8 3 negat ive, 2 1 9 posit ive, 218 Cost benefit analysis, defined, 2 8 3 Critical path: defined, 2 8 3 overview of, 145–146 D Daily act ivit y checklist : overview of, 22 4–225 sam ple, 226 Dat abase adm inist rat or ( DBA) , 176 Deadline, defined, 2 8 3 Delegat ion, 186 –187 Deliverables, defined, 2 8 3 –284 Dependency, 284 Design aut horit y, defined, 2 8 4 Design phase, 5 9 Developm ent : involvem ent wit h, 188 –190 overview of, 187–188 plan, 1 6 8–170 , 284 Discovery phase, 58

Docum ent at ion: archiving of, 2 6 6– 268 business, 1 0 6 com m unicat ion plan, 1 6 6 cont ingency plan, 1 6 3 –165 developm ent plan, 1 6 8 –170 procurem ent plan, 1 6 5 –166 proj ect m anagem ent plan, 1 6 1–163 t est and qualit y plan, 1 6 6 –168 updat ing of, 235 Durat ion, defined, 2 8 4 E Earned value: defined, 2 8 4 form ulas for, 220 , 221 overview of, 216–225 E- com m erce, diagram of, 6 2 Effort : defined, 2 8 4 overview of, 148–155 E- m ail, 4 7 –48 End- user, role of in proj ect analysis, 9 4 Ent it y relat ionship diagram ( ERD) t echnique, 9 8 Environm ent , 16 Est im at ion: accuracy of, 153 bot t om - up, 151 defined, 2 8 4 of effort , 148–151 necessary it em s in, 1 4 8 overview of, 146–147 phased, 152 –153 process of, 147 of profit , 153– 154 t op- down, 151 Execut ion phase, 5 9 , 288 Execut ives: com m it m ent t o st rat egy, 15 core funct ions of, 9–1 0 lessons for, 2 6–2 7 proj ect analysis and, 8 6 relat ionship wit h proj ect m anagers, 9– 10 F Feasibilit y:

defined, 2 8 4–285 overview of, 110–115 5 0- 50 rule, 2 2 1– 223 diagram of, 222 Firm fixed- price cont ract s, 160–161 Funct ional t est ing, 1 9 6–197 G Gant t chart : defined, 2 8 5 vs. earned value, 2 1 9 overview of, 140–143 Goal, 2 8 5 Go/ no go decision: defined, 2 8 5 overview of, 122–124 H Hardware, 104–105 Help desk, 2 7 5–276 Hum an Genom e Proj ect , 278 Hum an resources, 11– 12 I I dent ificat ion phase, defined, 2 8 5 I m plem ent at ion: approaches t o, 244–247 checklist for, 246 crash, 245– 246 day of, 253 –255 m eet ings, 247 overview of, 243–244 parallel, 2 4 4 –245 phase of, 59 phased, 245 plan for, 246 –247, 285 risks during, 2 5 5 st rat egy, 285 I nform at ion syst em s ( I S) , 1 2 I nform at ion t echnology ( I T) : archit ect ure, 1 0 3–106 com m ercial off- the- shelf solut ions ( COTS) , 115 , 118– 121 defined, 2 8 5 developm ent , 168 , 187 –190 enhancem ent s, 276

exist ing syst em s, 120 –121 hardware, 104 infrast ruct ure, 1 0 5 new solut ions, 121 –122 proj ect m anager's responsibilit ies, 4 9 prot ot yping, 1 7 8–179 soft ware developm ent , 105 , 168 , 174 , 187– 190 st rat egy, 1–1 5 t echnical aut horit y, 4 1 –42 I nfrast ruct ure: defined, 2 8 5 est ablishm ent of, 173 overview of, 170–173 preparat ion of, 249– 250 in proj ect analysis, 1 0 5–106 I nt egrat ion: considerat ions for, 6 4–6 5 testing, 1 9 8– 199 I ssues: defined, 2 8 6 log, 2 2 8 , 286 K Kick- off m eeting: defined, 2 8 6 diagram of, 125 for proj ect analysis, 1 2 4 in proj ect execut ion, 184 L Lessons learned: analysis, 1 2 4 –127 becom ing an I T proj ect m anager, 51– 52 concept s, 83 cont rol, 240 im plem ent at ion, 2 5 7–259 st rat egy, 26– 27 Life cycle, defined, 2 8 6 Life cycle dem and analysis ( LCDA) : overview of, 101–102 sam ple I T solut ion, 1 0 2 Linear responsibilit y chart ( LRC) : defined, 2 8 6 overview of, 157–158

M Maint enance, at closure, 273– 278 Market ing senior vice president , in st rat egic plan, 2 2 Mat rix m anagem ent , vii Met hodology: defined, 2 8 6 life cycle and, 5 6 –57 life cycle dem and analysis ( LCDA) , 101 –102 syst em developm ent life cycle ( SDLC) , 5 4–5 6 Milest one: defined, 2 8 6 plan, 2 8 6 Mission: defined, 1 3 st at em ent , 19– 20 Monitoring, defined, 2 8 6 N Net present value ( NPV) : calculat ion of, 114 defined, 2 8 6–287 Net work diagram , 287 Norgay, Tenzing, 3 0 O Obj ect ives, defined, 1 3 Offshore proj ect s, 122, 172– 173 Off- sit e proj ect s, 172 On- sit e proj ect s, 172 Operat ions m anagem ent : vs. program m anagem ent , 11 vs. proj ect m anagem ent , 1 1 Outsourcing, 1 2 2 P Param et ric est im at ion, 151 Perform ance t esting, 1 9 9 Phase, defined, 2 8 7 Phase com plet ion checklist : analysis, 1 2 8 –129 becom ing an I T proj ect m anager, 52 closure, 279– 280 cont rol, 242 execut ion, 208

im plem ent at ion, 2 5 9 planning, 180 –181 Phased est im at ion, 152 –153 Pilot t est ing, 1 9 6 Planning: diagram of, 133 initial, 1 3 5 –146 m ain t asks, 136 overview of, 131–135 resources and, 155– 157 See also Proj ect plan Post - proj ect review, 270 –271 Price, defined, 1 1 1–112 Procurem ent : of equipm ent and services, 204– 205 overview of, 70 –72 plan, 1 6 5–166 , 287 vendor select ion crit eria, 7 1 Product Breakdown St ruct ure ( PBS) , 137 diagram of, 138 Professionalism , defined, 4 5 Program m anagem ent : vs. operat ions m anagem ent , 1 1 vs. proj ect m anagem ent , 1 1 Program m anager, role of in proj ect analysis, 9 3 Proj ect , defined, 2 8 7 Proj ect closure report . See Closure, report Proj ect conclusion. See Closure Proj ect definit ion: defined, 2 8 7 report ( see Proj ect plan) Proj ect direct or, defined, 2 8 7 –288 Proj ect folder: at closure, 264–265 defined, 2 8 8 Proj ect infrast ruct ure. See I nfrast ruct ure Proj ect life cycle: diagram of, 6 1 overview of, 56 –57 phases of, 5 7–6 0 Proj ect m anagem ent : agenda, 185 analysis ( see Analysis) archiving, 2 6 6–268 at t ribut es, 3 7 –39 budgeting, 1 1 1 , 158, 202– 204 cat egories, 7 6– 79 chart er, 1 6– 17

checklist s, 2 7 , 52 , 128 , 279 classificat ion of, 7 6 closure, 265 , 269 cont rol, 209 –216 definit ion report , 163 elem ent s of, 3 2 est im at ion of, 146– 148 fact ors affect ing, 6 3 feasibilit y, 1 1 0–115 folder, 2 6 4 im plem ent at ion, 2 5 4 , 257 init iat ion, 134 m anagem ent plan, 1 6 1– 163 m onit oring overview of, 209–212 relat ed correct ive act ions on proj ect s, 210 office defined, 2 8 8 diagram of, 7 3 roles of, 72– 75 , 154 –155 vs. operat ions m anagem ent , 1 1 planning, 131 –132 (see also Proj ect plan) procurem ent , 70 , 204– 205 vs. program m anagem ent , 11 reporting, 2 3 7– 240 reviews: defined, 2 8 8 post - proj ect , 265 , 270 risks, 2 5 5 schedule (see Schedule) scope, 89 –90 , 206 sponsor (see Sponsor) t em plat es (see Tem plat es) t est ing ( see Testing) t ransit ion of client expect at ions, 55 t rends in, 3 0 –34 t ypes of, 75 –79 warning signs, 7 7 Proj ect Managem ent I nst it ut e ( PMI ) , 7 2 Proj ect m anagers: appoint m ent of, 3 6–3 7 charact erist ics of, 37 –49 as consult ant s, 4 6 defined, 2 8 8 fut ure of, 5 1 ident ificat ion of, 3 4– 37 I T responsibilit ies of, 4 9 role of in proj ect analysis, 9 2 –9 3 select ion of, 36 –37

skills needed by, 3 8 underst anding need for, 4 0 relat ionship wit h execut ives, 9 – 10 Proj ect phases: closure phase, 60 concept phase, 58 design phase, 5 9 discovery phase, 5 8 execut ion phase, 59 im plem ent at ion phase, 5 9 m aint enance phase, 273– 275 Proj ect plan: approach t oward, 165 cont ent s of, 162, 164 defined, 2 8 8 developm ent plan and, 1 6 9 execut ion of, 183–187 vs. proj ect chart er, 16 overview of, 161–163 Proj ect priorit izat ion list , 2 4 Proj ect review questionnaire, 265 Proj ect s in Cont rolled Environm ent s, 287 Proj ect t eam : defined, 1 4 , 292 delegat ion of t asks, 186– 187 developm ent of, 184 proj ect analysis and, 8 5 proj ect m anager's role in select ing, 4 3 –4 4 scope and, 9 0 unit t est ing and, 1 9 5 virt ual diagram of, 4 8 m anagem ent of, 4 6–4 9 Prot ot yping, defined, 2 8 9 Q Qualit y assurance ( QA) : defined, 2 8 9 diagram of, 236 overview of, 236 phases of, 5 9 proj ect t est ing and, 1 9 0– 191 qualit y m anagem ent and, 234 role of, 247–249 Qualit y cont rol: defined, 2 8 9 diagram of, 236

overview of, 236–237 qualit y m anagem ent and, 234 Qualit y m anagem ent , 234– 240 Qualit y plan, 2 8 9 R Rapid applicat ion developm ent ( RAD) , 179 , 289 Readiness review, 256 –257 Regional account m anager, in st rat egic plan, 2 2 Request for Proposal ( RFP) : at closure, 264 defined, 2 8 9 overview of, 109–110 sm all proj ect s and, 7 8 Requirem ent s, obt aining, 9 4 –96 Research and developm ent , phased est im at ion and, 152 Resources: cont rol of, 213–214 leveling of, 214 plan for, 289 pool, 289 release of, 272–273 select ion of, 155–157 Ret urn on invest m ent ( ROI ) : calculat ion of, 116– 117 defined, 2 8 9 est im at ion of, 114– 115 proj ect analysis and, 8 8 Risk: analysis of, 6 7 avoidance t echniques and m et hods, 68 cont rol of, 225–229 defined, 2 9 0 diagram of, 6 6 event s, 66 ident ificat ion of, 6 7– 69 im plem ent at ion and, 2 5 5 log, 2 2 7–228 m anagem ent of, 6 5–6 9 m it igat ion of, 69 plan, 2 9 0 report ing of, 6 9 Roles and responsibilit ies, 1 5 7 S Schedule:

cont rol of, 212–213 , 218 defined, 2 9 0 preparat ion of, 140– 143 sam ple, 141 variance, 2 9 0 Scope: changes t o, 231 defined, 2 9 0 developm ent plan and, 1 6 9 ident ificat ion of, 8 9– 90 Scope creep: m anagem ent of, 206– 207 proj ect m anagers and, viii, 6 Senior execut ives. See Execut ives Service level agreem ent ( SLA) : aft er closure, 274 , 276 defined, 2 9 0 t echnical support t raining and, 2 5 3 Sherpas, 3 0 Soft ware, 105 Solut ions: cust om ized, 120 new, 121–122 proposing, 1 1 5– 124 senior vice president of, 2 2 Sponsor: defined, 1 4 , 290 im port ance of in I T proj ect s, viii responsibilit ies of, 32 –34 sam ple accept ance checklist , 3 4 St aff reskilling, 2 7 1 St akeholders, defined, 2 9 0 –291 St art - to - finish, 1 4 3 St art - to -st art , 143 St at em ent of Work ( SOW) : at closure, 264 defined, 2 9 1 overview of, 110 Request for Proposal and, 1 0 9 St at us report s: defined, 2 9 1 overview of, 237–240 sam ple, 241 St eering com m it t ee, defined, 2 9 1 St rat egic proj ect s, defined, 1 1 St rat egy: achievem ent of, 3– 6 defined, 2 9 1

developm ent of, 23 diagram of, 4 execut ives' com m it m ent , 15 leadership, 8 – 1 0 levels of wit hin organizat ions, 5 m anagem ent 's com m it m ent , 14– 15 overview of, 1– 3 plan, 1 9 –23 on a proj ect life cycle, 1 3 proj ect m anagem ent involved in, 6 purpose of, 6 –8 requirem ent s, 13 –14 on st rat egic plan, 2 1 –2 2 t ranslat ion of int o proj ect s, 12 –13 St ress t est ing, 1 9 9 Subj ect Mat t er Expert ( SME) : bot t om - up est im at ion and, 152 defined, 2 9 1 est im at ion of effort and, 150 proj ect schedule and, 1 4 2 role of in proj ect analysis, 9 3 Work Breakdown St ruct ure and, 1 3 6 Sun Tzu, 5 , 2 3–2 4 , 42 , 45 , 132 Suppliers, defined, 2 9 1 Support , at closure, 273–278 SWOT ( st rengt hs, weaknesses, opport unit ies, and t hreat s) analysis: defined, 2 9 1 diagram of, 101 overview of, 99 –101 in st rat egic analysis, 1 9 –2 3 table, 2 0 Synergy, 9 Syst em developm ent life cycle ( SDLC) : ent it y relat ionship diagram and, 9 8 I T proj ect s and, viii– ix overview of, 54 –56 System testing, 1 9 7 –198 Syst em s analyst : defined, 2 9 1 role of in proj ect analysis, 9 2 T Tasks, defined, 2 9 1 Team . See Project team Technical aut horit y, 4 1 Technical design, 1 7 4– 179 Tem plat es:

defined, 2 8 8 use of, 79 Test and qualit y plan, 1 6 6 –168 Testing: accept ance t est ing, 1 9 9 crit eria for, 1 9 3–194 environm ent for, 191 –193 funct ional t est ing, 1 9 6 –197 im port ance of, 193–202 int egrat ion t est ing, 1 9 8– 199 overview of, 190–193 pilot testing, 1 9 6 st ress t est ing, 1 9 9 sy st em s t est ing, 197 –198 t est cases, 201 t est crit eria, 1 9 3 t est script s, 2 0 1 t ypes of, 194 unit testing, 1 9 4 –195 Tim e sheet s: daily proj ect act ivit ies checklist , 2 2 4–225 sam ple, 226 frequency checklist s, 2 2 5 overview of, 223–224 Tim e- and- m at erials cont ract s, 161 Tim eboxing approach: proj ect t est ing and, 1 9 0 overview of, 55 –56 Top- down estim ation, 151 Training: infrast ruct ure, 2 5 2 overview of, 250–257 t echnical support , 252– 253 U Unit t est ing, 1 9 4– 195 User requirem ent st at em ent ( URS) : defined, 2 9 2 descript ion of, 108 –109 diagram of, 1 09 requirem ent s and, 9 5 V Values, corporat e, 2 0–2 1 Version cont rol, 231 Virt ual proj ect s, 4 6–4 7

Vision, 1 9 Voicem ail, 4 7 W Wat erfall approach: proj ect t est ing and, 1 9 0 overview of, 55 –56 Work Breakdown St ruct ure ( WBS) : bot t om - up est im at ion and, 151 –152 cont rol of proj ect cost s and, 215 –216 cont rol of proj ect schedule and, 2 1 3 defined, 2 9 2 diagram of, 138 est im at ion of effort and, 150 linear responsibilit y chart and, 157 –158 overview of, 136–137 procurem ent and, 7 0– 72 profit est im at ion and, 1 5 3–154 proj ect est im at ion and, 147 request for proposal and, 1 0 9 t op- down est im at ion and, 151 Workflow process t echnique: diagram of, 100 overview of, 98 –99

List of Figu r e s Cha pt e r 1 : Underst anding Proj ect St rat egy Figure 1 .1 : Underst anding proj ect st rat egy Figure 1 .2 : Proj ect m anagem ent involvem ent in form ulat ing st ra t egies Figure 1 .3 : The basic beginnings of st rat egy on a proj ect life cycle Figure 1 .4 : The originat ion of t he chart er Figure 1 .5 : The priorit iza t ion of your proj ect port folio Cha pt e r 2 : Becom ing an I T Proj ect Manager Figure 2 .1 : The elem ent s of proj ect m anagem ent Figure 2 .2 : Skills needed by proj ect m anagers Figure 2 .3 : Underst anding t he need for good proj ect candidat es Figure 2 .4 : W orking w it h decent ralized t eam s and proj ect s Cha pt e r 3 : Proj ect Concept s Figure 3 .1 : Managing t he proj ect t hrough it s life cycle Figure 3 .2 : An exam ple of a t ypical e- com m erce proj ect m et hodology Figure 3 .3 : Underst anding proj e ct risk m a na gem ent Figure 3 .4 : The proj ect office dependency Figure 3 .5 : Classificat ion of I T proj ect s Figure 3 .6 : Managing change on t he proj ect Cha pt e r 4 : The Proj ect Analysis Figure 4 .1 : Basic ent it y relat ionship diagram Figure 4 .2 : A classic w orkflow process Figure 4 .3 : SW OT analysis diagram Figure 4 .4 : Business im pact analysis diagram Figure 4 .5 : Business case diagram Figure 4 .6 : User requirem ent s st at em ent diagram Figure 4 .7 : Project kick - off m eet ing involvem ent Figure 4 .8 : Overview of analysis t ask s

Cha pt e r 5 : Planning for Success Figure 5 .1 : Planning phase act ivit ies Figure 5 .2 : The w ork breakdow n st ruct ure ( W BS) chart Figure 5 .3 : The product breakdow n st ruct ure ( PBS) chart Figure 5 .4 : Preparing t he schedule Figure 5 .5 : Defining t ask relat ionships Figure 5 .6 : Arrow net w ork diagram Figure 5 .7 : Consolidat ing proj ect cost s Figure 5 .8 : Bot t om up est im at ing Figure 5 .9 : Cost ing m odels Figur e 5 .1 0 : Proj ect plan cont ent s Figur e 5 .1 1 : The t echnical approach Cha pt e r 6 : Execut ing t he Proj ect Figure 6 .1 : A basic proj ect agenda Figure 6 .2 : I T st aging environm ent s Figure 6 .3 : Managing t he proj ect cash flow Cha pt e r 7 : Cont rolling t he Proj ect Figure 7 .1 : Elem ent s of proj ect cont rol Figure 7 .2 : Resource leveling Figure 7 .3 : Cont rolling bot h proj ect schedule and cost Figure 7 .4 : Earned value form ulae Figure 7 .5 : The 5 0 - 5 0 rule t echnique Figure 7 .6 : Daily proj ect act ivit y check list Figure 7 .7 : Cont rol issues t o m onit or Figure 7 .8 : Qualit y assurance and cont rol Figure 7 .9 : High- level ex ecut ive sum m a ry Figur e 7 .1 0 : Generic proj ect st at us report

List of Ta ble s Cha pt e r 1 : Underst anding Proj ect St rat egy Ta ble 1 .1 : St rat egy levels w it hin orga niza t ions Ta ble 1 .2 : Uniquenesses bet w een operat ions proj ect and program m a na gem ent Ta ble 1 .3 : Com pany xx, I nc., SW OT analysis Cha pt e r 2 : Becom ing an I T Proj ect Manager Ta ble 2 .1 : Typical proj ect sponsor accept ance check list Ta ble 2 .2 : Team select ion checklist Ta ble 2 .3 : I T proj ect m anager responsibilit ies Cha pt e r 3 : Proj ect Concept s Ta ble 3 .1 : Transit ion of client expect at ions in proj ect m a na gem ent Ta ble 3 .2 : Com parison of w at erfall and t im eboxing proj ect m ethodolo gie s Ta ble 3 .3 : Various proj ect m et hodology approaches Ta ble 3 .4 : Fa ct ors affect ing proj ect m anagem ent Ta ble 3 .5 : Risk avoidance t echniques and m et hods Ta ble 3 .6 : Vendor select ion crit eria Ta ble 3 .7 : W hat proj ect it em s t o ident ify and pace under configurat ion cont rol Cha pt e r 4 : The Proj ect Analysis Ta ble 4 .1 : I ssues a ddressed in t he a na lysis a nd a ssessm ent pha se Ta ble 4 .2 : Technical t eam support during t he analysis phase Ta ble 4 .3 : I nt erna l a nd ex t erna l a na lysis fact ors Ta ble 4 .4 : LCDA of a proposed I T solut ion Ta ble 4 .5 : Benefit s of having business docum ent at ion in place Ta ble 4 .6 : Calculat ing t he benefit - cost analysis ( w hen profit is com put ed in num erat or) Ta ble 4 .7 : Ca lcula t ing ROI Ta ble 4 .8 : I m pact of cust om izing a st andard pack age

Ta ble 4 .9 : Out sourcing I T t o cont ract ors Cha pt e r 5 : Planning for Success Ta ble 5 .1 : M ain proj ect planning t ask s Ta ble 5 .2 : W hat t o include in a proj ect est im at e Ta ble 5 .3 : Param et ric m odeling Ta ble 5 .4 : Resource skills required by proj ect Ta ble 5 .5 : Planning for resource usage Ta ble 5 .6 : Proj ect budget and m ont hly budget ( $ ) Ta ble 5 .7 : Proj ect plan cont ent Ta ble 5 .8 : Proj ect plan approach Ta ble 5 .9 : Design t echniques used in t he design phase Ta ble 5 .1 0 : Technical specif icat ion cont ent Cha pt e r 6 : Execut ing t he Proj ect Ta ble 6 .1 : Va rious t ypes of proj ect t est ing Cha pt e r 7 : Cont rolling t he Proj ect Ta ble 7 .1 : Monit oring a nd rela t ed correct ive a ct ions on a proj ect Ta ble 7 .2 : Earned value form ulae Ta ble 7 .3 : Frequency check list Ta ble 7 .4 : Risk and issue m at rix Ta ble 7 .5 : Change cont rol t racking list Cha pt e r 8 : I m plem ent ing t he Proj ect Table 8 .1 : Support levels t hat need t o be accom m odat ed Cha pt e r 9 : Closing t he Proj ect Ta ble 9 .1 : Fact ors affect ing proj ect closure Ta ble 9 .2 : Post - proj ect review st aff Ta ble 9 .3 : Sharing a com m on resource pool