Section A (20 Marks) Write short notes on any four of the following: 1. Rework backlog 2.

Evaluation of project management systems 3. ualities of a successful project manager !. "lanning for procurement #. $echnical evaluation Section B (30 marks) (Attempt any three) 1. %efine "roject &ontrols. What are the important approaches of project control' (riefly e)plain the project control cycle. 2. What are in*ivi*ual *iscipline +,+ - (ell curves' .ow these curves help in monitoring control of major activities/area of work' 3. 0"roject success *epen*s upon accuracy of cost estimate+. ,ubstantiate this by suitable e)ample. E)plain the basic engineering cost control. !. .ighlight the two basic strategies of controlling fee*backs. E)plain overtime1 workforce si2e1 an* work intensity on rework. the impacts of

Section C (50 marks) (Attempt all questions. E ery question carries !0 marks) Rea* the case an* answer the following 3uestions: Ma"or Causes o# So#t$are %ro"ect &ailures 4ost software projects can be consi*ere* at least partial failures because few projects meet all their cost1 sche*ule1 3uality1 or re3uirements objectives. 5ailures are rarely cause* by mysterious causes1 but these causes are usually *iscovere* post6mortem1 or only after it are too late to change *irection. $his article is base* on interviews with software consultants an* practitioners who were aske* to provi*e 7autopsies7 of faile* projects with which they have been ac3uainte*. 8lthough not a comprehensive compilation of failure causes1 this article outlines several areas that shoul* *eman* your attention.

5ew years ago marke* the rollout of what coul* have been calle* a $itanic of military projects1 e)cept the original $itanic was ahea* of sche*ule when it sank. .un*re*s of millions of *ollars over bu*get an* years behin* sche*ule1 the first phase of this huge military system was finally 7tosse* over the wall7 an* over the top of a network of separate programs use* by thousan*s of practitioners. 8lthough long hampere* by 3uality problems1 big hopes were again ri*ing on the system once it passe* acceptance testing. $he inten*e* users refuse* to use the system. 9t lacke* features they sai* were essential to their jobs while re3uiring steps they consi*ere* unnecessary or bur*ensome. $he project eventually *ie* a visible1 painful *eath ami* litigation an* congressional in3uiries. $his faile* project was not atypical of chronic problems in the software in*ustry. 8ccor*ing to the ,tan*ish :roup1 in 1;;#1 <.,. government an* businesses spent appro)imately =>1 billion on cancele* software projects1 an* another =#; billion for bu*get overruns. $heir survey claime* that in the <nite* ,tates1 only about one6si)th of all projects were complete* on time an* within bu*get1 nearly one thir* of all projects were cancele* outright1 an* well over half were consi*ere* 7challenge*.7 ?f the challenge* or cancele* projects1 the average project was 1>; percent over bu*get1 222 percent behin* sche*ule1 an* containe* only @1 percent of the originally specifie* features. ?ther stu*ies have likewise conclu*e* that failure is rampant1 although not necessarily to the same *egree. ?ne reason for the varie* conclusions is that most faile* projects are never stu*ie* Aeven by the organi2ation that e)perience* the failure. .aving waste* so much on a fruitless venture1 few organi2ations will invest more time or money to collect an* analy2e a**itional *ata1 whereas any *ata that ha* been collecte* may be massage* or hi**en to protect careers or reputations. $hus1 information about project failures often relies heavily on subjective assessments. $his article is no e)ception. 5or this article1 a failure is *efine* as any software project with severe cost or sche*ule overruns1 3uality problems1 or that suffers outright cancellation. 9t is base* on interviews with practitioners an* consultants who were aske* to *escribe the causes of software project failures with which they have been ac3uainte*. 9f there is anything notable about the interviewees+ *iagnoses1 perhaps it is that many of these problems have been *ocumente* for years1 but somehow they keep cropping up. 8lso worth noting is that most of the failure causes mentione* originate before the first line of co*e has been written. $he failure causes are liste* in no particular or*er. %oor 'ser (nput 8lthough the $itanic project mentione* earlier was ri**le* with problems1 it ultimately faile* because the system *i* not meet user nee*s. 8ccor*ing to "aul .ewitt1 a consultant with the ,oftware $echnology ,upport &enter B,$,&C1 the ac3uirers an* the *evelopers of this system ha* receive* most of their re3uirements from higher6level supervisors an* so6calle* 7users7 who were not regularly using the e)isting system. 8lthough 7not invente* here7 syn*rome contribute*

to the system+s eventual lack of acceptance1 the bottom line is that the system was ina*e3uate for its environment. (y contrast1 .ewitt has observe* successful programs in which 7en* users an* *evelopers working together in the same cubicle.7 8lthough this is not always possible1 .ewitt sai* projects are likely hea*e* for trouble unless informe* en* users are giving meaningful input *uring every phase of re3uirements elicitation1 pro*uct *esign1 an* buil*ing. $he input nee*e* by these users has less to *o with issues like screen layouts than with how the system woul* be use* in the fiel*1 accor*ing to 4ichael 8llen Datta1 chief e)ecutive officer of ?hana $echnologies &orp. in Dafayette1 &olo. .e sai* the user shoul* be asking1 7.ow *o 9 use it over time' %oes it provi*e the right tools' What *o 9 put into it1 an* what *o 9 get out'7 .owever1 there can also be problems if the users are too close to the re3uirements. ,hari Dawrence "fleeger1 presi*ent of ,ystems/,oftware in Washington1 %.&.1 ha* just starte* consulting on a large fe*eral system ac3uisition when she starte* to stu*y its re3uirements1 which were suppose*ly 7clean7 *ue to the input of highly knowle*geable users. Even without any prior un*erstan*ing of the system or its fiel* environment1 "fleeger nee*e* only a few hours to see that the re3uirements were full of hi**en assumptions an* conflicts. 7$he users *i*n+t think of the conse3uences of what they were re3uiring17 she sai*. 7$hey assume* that how things were *one in the past was how they woul* always be *one in the future.7 $he users assume* the elicitors un*erstoo* more than they *i* about the users+ jobs1 but this was not entirely the users+ fault. 8ll involve* parties1 inclu*ing the *evelopers1 must un*erstan* the business of the other parties. $his nee* continues throughout *evelopment process. Without this un*erstan*ing1 the parties 7*on+t even know what 3uestions to ask17 "fleeger sai*1 an* important issues fall between the cracks. Stakehol)er Con#licts 8 few years ago1 a major airline1 rental car company1 an* some hotel chains create* an incentive plan to give customers fre3uent flier6type points to 7cash in7 for any of the participating companies+ services. $hey commissione* a comple) software system to track points an* compensation. ,ometime later1 the software *evelopers nee*e* some clarifications1 i.e.1 with input 81 *oes the system choose E1 F1 or G' $he stakehol*ers coul* not agree on the answers. 5orce* to acknowle*ge *eep incompatibilities among their business interests1 the system was cancele* in an e)pensive1 litigious failure of the entire enterprise. $he stakehol*ers ha* worke* un*er 7the illusion that everyone was going to get everything that they wante*17 e)plaine* $om %e4arco1 principle of the 8tlantic ,ystems :uil*. $hey 7papere* over their *ifferences7 rather than going through conflict resolution in the early stages. $heir *ifferences were e)pose* by the *evelopers because 7co*ers cannot make an ambiguous system.7 ,takehol*er conflicts can play many *ifferent roles project failures. 5or e)ample1 7some projects are ultimately cancele* because people *on+t like each other17 sai* &apers Hones1 chairman of ,oftware "ro*uctivity Research1 9nc.

?ther projects fail because the *evelopers *o not know who the 7real7 stakehol*ers are1 accor*ing to E* Four*on1 chairman of the &utter &onsortium. Four*on worke* with a large mutual fun* company that ha* been working on a =3II million software system. $he *evelopers ha* been working closely with the information technology vice presi*ent1 who was perceive* to be the primary stakehol*er for the system. When the system ran into some problems1 it *rew the attention of the chief e)ecutive officer1 who turne* out to be the real stakehol*er in the system even though he ha* not previously been involve* with it. 8fter seeing the involve* risks1 he imme*iately with*rew his support for the system. 7Jo one bothere* to ensure that he was going to support it17 Four*on e)plaine*. 7Jo one ma*e him aware of problems while it was being *evelope*.7 Four*on says many projects fail because the project lea*ers *o not have a sense of who will ultimately *eclare whether a project is a success or failure1 an* then they are 7blin*si*e*.7 .e sai* the true stakehol*ers nee* to hear goo* an* ba* news in 7small pieces7 rather than in 7one chunk.7 ?ther projects1 especially smaller projects within larger projects1 never go anywhere because the internal stakehol*ers never agree on priorities. Watts .umphrey1 a fellow at the ,oftware Engineering 9nstitute1 calls these 7preten* projects17 meaning a few *evelopers work on them half time or 3uarter time1 an* nothing is ever *elivere*. 7$hey are ki**ing themselves that they are working on these projects17 .umphrey sai*. 7Jo one can work 3uarter time on a project. K $hey haven+t face* the nee* as a management team to *eci*e what they are really going to *o with it. $hey nee* to put real resources on it7 rather than merely preten* the project is un*er way. *a+ue ,equirements 4ariea %ati21 presi*ent of "eripheral Lisions in .ouston1 $e)as1 learne* a har* lesson about what happens when a project is starte* while the re3uirements are nebulous. $he <.,. *ivision of an oil company hire* %ati2+s company to create the 7first *raft7 of a program so that they coul* impress their European counterparts an* justify further fun*ing. (ut the oil company officials only ha* a general i*ea of what the program was to *o an* trie* to revise an* refine their i*eas while %ati2+s company was working on the program. 75or every step we woul* take1 we+* go three backwar*17 %ati2 sai*. 7We woul* start *own one path an* then have to stop an* go *own another.7 "roject cost an* 3uality 3uickly went out of control1 her company was blame*1 an* she lost the contract to finish the job. Dike many faile* projects1 the scope ha* not been narrowe* enough at the outset to have le* to any reasonable chance for success. ?ne obvious solution is to establish a reasonably stable re3uirements baseline before any other work goes forwar*. (ut even when this is *one1 re3uirements will still continue to creep. 7Fou can+t *esign a process that assumes re3uirements are stable17 a*vises .umphrey. 9n virtually all

projects1 there will be some *egree of 7learning what the re3uirements really are while buil*ing the pro*uct17 he sai*. "rojects coul* be hea*e* for trouble if architectures an* processes are not change6frien*ly1 or if there are poorly establishe* gui*elines that *etermine how an* when re3uirements can be a**e*1 remove*1 an* implemente*Aan* who will shoul*er the cost of the changes. %oor Cost an) Sche)ule Estimation 9t is unfair to call a project a failure if it fails to meet bu*get an* sche*ule goals that were inherently unattainable. Dike all engineering en*eavors1 every software project has a minimum achievable sche*ule an* cost. 5re*rick (rooks summari2e* this law in $he 4ythical 4an 4onth when he state*1 7$he bearing of a chil* takes nine months1 no matter how many women are assigne*.7 8ttempts to circumvent a project+s natural minimum limits will backfire. $his problem occurs any time someone 7makes up a number an* won+t listen to anyone about how long other projects took17 sai* Hones. 8ccor*ing to %e4arco1 projects are often intentionally un*erbi* because of the 7attitu*e that putting a *evelopment team un*er sufficient pressure can get them to *eliver almost anything.7 $he opposite is what usually happens. 5or e)ample1 if a program shoul* realistically take five programmers one year to complete1 but instea* you are given four programmers an* eight months1 you will have to skimp on *esign time an* on 3uality checks to reach project milestones. 7&utting a corner that un*ermines the entire foun*ation of the project is not cutting the corner17 states Robert :e2elter1 a software consultant in 5lushing1 Jew Fork. 7$here will be heavily *isproportionate costs *ownstream.7 ,kimping lea*s to weak *esigns1 *ramatically higher *efect *ensities1 much more rework1 an* virtually en*less testing. 9n the en*1 the project will cost more1 take longer1 an* have worse 3uality than woul* have been possible if a realistic sche*ule an* bu*get ha* been followe*. 8ccor*ing to Hones1 this problem can be easily reme*ie*. ,everal estimation tools on the market can combine numerous variables to provi*e realistic estimates within a few hours1 even at the early critical *ecision6making juncturesAbefore re3uirements are firm. Skills that -o .ot Match the /o0 %eca*es ago1 4orris %ovey1 information *irector for &heck &ontrol1 9nc. in West %es 4oines1 9owa1 worke* on major government software contracts before becoming so frustrate* he *eci*e* to never work with government contracting again.

79t was being ma*e artificially *ifficult17 %ovey sai*. $he technologists ha* to en*ure what he consi*ere* avoi*able *elays an* mistakes because 7*ecisions were being ma*e by people with no technical e)pertise in the area7 but ha* all the authority. Datta warns that managers can perform poorly if they lea* projects that *o not match their strengths. 7"rojects *ealing with high technology nee* managers with soli* technical skills17 Datta a*vises. 9n such projects1 authority must resi*e with people who un*erstan* the implications of specific technical risks. .owever1 the best technologists are not necessarily always poise* to be the best managers. 7$he skill set for management an* programming are *isjoint17 Hones observe*. $he larger the project1 the more nee* there is for people with e)cellent planning1 oversight1 organi2ation1 an* communications skillsM e)cellent technologists *o not necessarily have these abilities. ,kill6*riven challenges are not limite* to management. "oor *evelopers can sap pro*uctivity an* make critical1 e)pensive errors. :eneralists can also poorly perform *uties better left to specialists1 such as metrics e)perts or testers. $he solution to skill6*riven challenges is easy to *efine but *ifficult an* e)pensive to accomplish: 8ttract an* retain the most highly skille* an* pro*uctive people. 7Nnowle*ge is money17 note* $om "ennington1 senior network manager for $he 49D &orporation in 8rlington1 La. .owever1 there is an eventual payback. "ennington believes a team ma*e up of higher6pai* people with the right speciali2e* skills is worth far more per *ollar to an organi2ation than a group of lower6cost people who nee* weeks or months of fumbling through a new process or technology before they can start being pro*uctive. 7Fou get what you pay for17 %ati2 echos. 7Fou+ll also pay for what you get.7 Hones a*vises that 7if you can+t get the best Otechies1+ get the best managers.7 .e sai* goo* managers can often get above6average results from average employees1 whereas great employees can have much of their potential s3uan*ere* by me*iocre management. 1i))en Costs o# 2oin+ 34ean an) Mean3 %e4arco believes project managers an* technologists are often unfairly blame* for problems cause* by people 7two levels higher.7 .e believes managers an* technologists are generally competent an* getting better every year1 but they are 7goa*e*7 into overtime work because of 7the 1;;Is stupi* flirtation with lean an* mean7Acutting jobs an* e)pecting the same work with fewer people an* less money1 whether such a feat is possible or not. %e4arco says the the often6 intentional 7*ishonest pricing7 of projects is often off by a factor of two or four or more1 re3uiring never6before6seen levels of performance.78ny failure will be viewe* as a *irect result of un*erperformance17 he charges1 even though un*erperformance is 7not even a significant

factor7 in the failure of most projects. 9nstea*1 he says1 the faile* projects simply ha* goals that were inherently unattainable. .umphrey has observe* a *ifferent 7lean an* mean7 problem. 9n many 7*ownsi2e*7 organi2ations1 he says1 *evelopers are *oing their own e)pense accounts1 clerical work1 software up*ates1 an* other *utiesAan* at a higher labor rate an* with less skill than coul* be performe* by support specialists. .e estimates that many software *evelopers are spen*ing half their work hours slowly plo**ing through tasks that have nothing to *o with *eveloping software. 7,oftware people are very unskille* clerks17 he sai*. 79t+s an enormous pro*uctivity issue.7 &ailure to %lan .umphrey took charge of commercial software *evelopment for 9(4 at a point when the company was taking too long to finish projects an* was missing all its announce* *ea*lines. 7"eople were working har*1 but no one ha* plans ... because no one re3uire* them to make plans17 .umphrey recalls. 9n response1 he re3uire* that a *etaile* plan be *evelope* before any release *ate was announce*. 5or the ne)t two an* one half years1 the *ivision never misse* an announce* *ate. 79f software *evelopers built bri*ges1 we+* show up at the site with some scrap iron an* say1 Olet+s start buil*ingP+7 3uippe* Reuel 8l*er1 a manager at the ,$,&. 8l*er agrees that ina*e3uate planning is a major reason software projects spin out of control. .umphrey sai* project managers often *o not plan because 7any plan they put together won+t meet the *esire* release *ate1 so they can+t plan.7 Even though *etaile* planning saves an enormous amount of time in the long run1 .umphrey says many other managers an* *evelopers believe it to be unnecessary. 7$hey think time spent on things like planning1 *esign1 re3uirements1 an* inspection gets in the way of real work1 which is co*ing an* testing17 he sai*. 7$his comes from the view of programming that the issue is to get the software out the *oor. (ut there+s a *ifference between spee* an* progress.7 7We nee* a lot fewer heroes17 a**s :e2elter. .e believes organi2ation 7heroics7 woul* fre3uently be unnecessary if projects ha* been properly planne*. 7We keep rewar*ing people for charging off on suici*e missions17 he sai*. Communication Break)o$ns When "fleeger was aske* to consult on a large project that was in trouble1 she aske* the managers to *evelop a process mo*el for the project. ,he *i* not necessarily want the mo*el for her own use1 but wante* the managers to talk to the *evelopers. ?nce they *i*1 they reali2e* the project ha* gotten so large that the same co*e was being teste* by two teams that *i* not know the other e)iste*. ,uch problems are common on large projects1 especially if people are working

at *ifferent sites. 9n many trouble* projects1 7there isn+t one person who has an overview of the whole project17 she sai*. Especially on large projects1 "fleeger a*vises that a**itional time be taken perio*ically to have everyone in every position learn the big picture. 7$he people working on the pieces nee* to know how their one piece fits into the entire architecture.7 %oor Architecture Pfleeger says an e)ample of fle)ible architecture is the "atriot missile use* *uring the :ulf War. 9t was not *esigne* to intercept scu* missiles1 but the software was able to be reconfigure* to support the new function. ?n the other en* of the fle)ibility spectrum was a security program create* to protect sensitive wor*6processing *ocuments. Everything worke* well for a few months until the operating system was up*ate*. $he wor*6processing programs still worke*1 but the security program became useless an* unfi)able because much of its co*e was tie* to operating system features that were *roppe* in the new system. 7"eople *i*n+t think ahea* about what was likely to change17 "fleeger sai*. 8rchitecture must allow for organi2ation an* mission changes. :e2elter sai* software *evelopers often buil* with no more forethought than the man who built a beautiful boat in his workshop an* then coul* not get it out the *oor. 79f you *o architecture right1 no one will ever reali2e it17 he sai*. 7(ut if you *o it wrong1 you will suffer *eath by a thousan* cuts. (a* choices show up as long6term limitations1 aggravation1 an* costs.7 :e2elter suggests viewing software architecture like house6buil*ing: 7"lumb7 an* 7wire7 for features an* a**itions you have not thought of yet. $hen1 when unanticipate* nee*s or business changes arise1 you can a** or mo*ify without performing the software e3uivalent of 7ripping apart the walls an* rebuil*ing them again.7 4ate &ailure 5arnin+ Si+nals %oes the following scenario by Four*on seem familiar' 8 sche*ule an* bu*get are *etermine* 7by e*ict by people you were afrai* to say no to17 an* it is politically unwise either to say or show the estimate is far from achieveable. 8ll your early milestones involve *iagrams1 *esigns1 an* other *ocuments that *o not involve working co*e. $hese an* other project milestones then go by more or less on sche*uleAat least as far as upper management can tellAan* testing starts more or less on time. Jot until the project is a few weeks from *ea*line *oes anyone *are inform the 7e*ict makers7 that at the current *efect *etection rate1 the project will not be complete* even close to its *ea*line. 7Jobo*y seems to acknowle*ge that *isaster is approaching17 Four*on sai*1 even among people who sense there is a problem. 7$here is no early warning signal.7 <ntil more organi2ations

aban*on waterfall6style *evelopment in favor of processes that *eman* early working co*e or prototypes1 he says this scenario will continue to be familiar. Four*on says the above problem is also e)tremely common with year 2III work. .e believes many year 2III conversion teams1 if they were allowe*1 woul* say of their current situation: 7Within this limite* time an* pitiful bu*get an* un*erstaffe* team1 sure1 we can *eliver it on timeA with a million bugs in it.7 9n a perfect worl*1 lower6level people coul* convince upper6level managers that their e*icts are unworkable before the project got un*er way. (ut until this happens1 Four*on says *evelopment cycles nee* to be a*opte* that allow you1 at the earliest possible moment1 to 7provi*e evi*ence that the project is or is not working.7 Conclusion ?ther causes of failure coul* be a**e* a* nauseam1 but the e)istence of a**itional factors is not the point. 8s Hones note*1 7$here are myria* ways to fail. K $here are only a very few ways to succee*.7 $he factors of successful project management have been *ocumente* for yearsAthey merely nee* greater attention. (ut if this article has helpe* serve as a reality check for your project1 it will have serve* its purpose. 9f you violate any of the principles note* by the consultants an* practitioners in this article1 you shoul* not e)pect to succee* in spite of yourself. 6uestions7 1. .ow vague re3uirements cause software failure'

2. ?f the 1I 5ailures of ,oftware "rojects how much is in the analysis versus buil* stage' 3. Who is the person most responsible to prevent failure of software projects' !. ,houl* the project manager be from the 9$ group' #. .ow poor architecture cause software failure'