Access UC's library and conduct a search for the journal with DOI:10.1109/52.765782, and titled "Critical success factors in software projects".Out of the sixteen (16) chapters in your text, select any FIVE (5) components (or chapters) of the text that are applicable to the journal, hence relating to the critical success factors identified in the journal. Critique the journal based on those FIVE (5) components, using your textandany other resource as a reference.For each selected component, specify whether you agree with the author or not, and provide your rationale accordingly. Add in-text citation and references

FOCUS Software projects are still late, over budget, and unpredictable. Sometimes the entire project fails before ever delivering an application. This clear, commonsense review of fundamental project management techniques reminds us that we still have a long way to go. . . Critical Success Factors In Software Projects John S. Reel, Trident Data Systems hroughout the fifty-odd years of software development, the industry has gone through at least four generations of programming languages and three major development paradigms. We have held countless sem- inars on how to develop software correctly, forced many courses into undergraduate degree programs, and introduced standards in our organizations that require specific technologies. Still, we have not improved our ability to suc- cessfully, consistently move from idea to product. In fact, recent studies document that, while the failure rate for software development efforts has improved in recent years, the number of projects experiencing severe problems has risen almost 50 percent.' There is no magic in managing software development successfully, but a number of issues related to software development make it unique. IEEE Software May/June 1909 0740-7459/99/$10.00 @ 1999 IEEE Authorized licensed use limited to: University of the Cumberla on August 21,2023 at 21:16:13 UTC from IEEE Xplore, Restrictions apply.Page 2 of 6 FOCUS FOCUS MANAGING COMPLEXITY Granted, even a detailed review of these may case your customers haven't heard, remind them The most critical element in selecting people is leave you wondering what's new here. Not much- routinely that this system will not solve all of their creating an environment in which they can excel, and Several characteristics of software-based en- this is common-sense, basic management stuff. And problems and it will probably create new issues. The that lets you focus more on technology than team deavors complicate management. First, software- yet these principles are not commonly employed. If new system should cost-effectively solve more prob- dynamics. You don't want a team of clones, but you based systems are exceptionally complex. In fact. they were, we would not see such high failure rates. lems than it creates. The developers must also un- do want people who are compatible with one an- many agree that "the basic problem of computing derstand that the customers do not know exactly other and with the company and team environment s the mastery of complexity."Because software de- what they want, how they wantit, or how it will help you are striving to establish. For example, a married- velopers must deal with complex problems, they are START ON THE RIGHT FOOT with-kids, laid-back, nine-to-five generally very intelligent and complex individuals, developer might not work well or which also complicates the management formula. It is difficult to call any of these factors most im- By the time you figure out you have a quality a team of young, single, forcefu Add the fact that developers are trying to hit a mov- portant, since they are all critical to the success of problem, it is probably too late to fix it. seven-to-eleven developers. This ing target-user requirements-and you get a large development efforts. However, getting a pro- doesn't mean the former is any volatile mixture of management issues. ject set up and started properly certainly leads this less qualified or productive These and many other influ- them. Often, they don't even know how much they Actually, that laid-back developer may produce bet ences contribute to a fantastically high failure rate among software At least seven of 10 signs of IS project failures can spend. Everyone has to come to the table with ter code and be more productive than the rest of the their eyes open, willing to cooperate and listen. To group. If you think that first person brings a calming development projects. The Chaos are determined before a design is developed avoid later heartache, pay strict attention to the focused influence without either "side" becoming study. published by the Standish commitments made by both sides overly frustrated, maybe it is a good fit after all. At Group, found that 26 percent of or a line of code is written. any rate, you must take these factors into consider- ill software projects fail (down Build the right team ation when building your team. from 40 percent in 1997), but 46 percent experience class of factors. Just as it is difficult to grow strong Next, you must put together the right team. Wherever possible, and it usually is possible, in- cost and schedule overruns or significantly reduced plants in weak soil, it is almost impossible to suc- First ensure that you have enough resources to get volve customers and users in the development. Not functionality (up from 33 percent in 1997).' The cessfully lead a development effort that is set up im- the job done. If you do not get commitments for only does this help build higher levels of trust be- study also shows that the completion rate has im- properly. Tom Field analyzed pitfalls in software de- resources up front, the effort is doomed. If man- tween developers and users, it also places domain proved because companies have trended towards velopment efforts and gave 10 signs of IS project agement is not excited enough about the effort experts within arm's reach of the developers smaller, more manageable projects-not because failures-at least seven of which are fully deter- to give it enough resources, you may not have the throughout development. This increases the chance the management techniques have improved. Can mined before a design is developed or a line of code support necessary for success. Remember, too, that you will develop a product that meets the user you imagine a construction firm completing only 74 is written. Therefore, 70 percent of the dooming that you will likely need more resources than you requirements. percent of its buildings and completing only 54 per- acts occur before a build even starts. think. We are all inherently optimistic, so guard cent of the buildings within schedule and budget? Here are 10 signs of IS project failure:3 your personnel projections and err on the high Give the team what they think they need To change this trend, we must place special empha 1. Project managers don't understand users' side from the start. Once you have built a strong team, you must next sis on certain factors of the management process. needs. Building the right team means getting good provide it with an environment that encourages pro- You may think the answers lie in elaborate analy- 2. The project's scope is ill-defined. people. This is hard because companies usually want ductivity and minimizes distractions. First, do your sis methodologies, highly advanced configuration 3. Project changes are managed poorly. to place personnel moving off other efforts. best to arrange quiet, productive office spaces. This management techniques, or the perfect develop- 4. The chosen technology changes. Sometimes these people are good resources, but is often impossible given most corporate realities, ment language. Those elements of the technology 5. Business needs change. not always. However, also recognize that you do not but a comfortable office setting can yield dramatic landscape are as important as highly scientific and 6. Deadlines are unrealistic need, or want, all of the very best designers and de- results. Highly productive environments contain analytical research in analysis and design method- 7. Users are resistant. velopers. In my experience, staffing around 20 per- white boards, meeting areas (formal and informal) ologies, project management, and software quality. 8. Sponsorship is lost. cent of the team with the best available works well. private office areas, and flexible, modern lab facili- However, blueprints of the latest train technology 9. The project lacks people with appropriate This figure is loosely supported in Fred Brooks' essay ties. Add comfort element ereos, light dim- didn't improve life in the Wild West until rail com- skills. "The Surgical Team." His team of about 10 people mers, coffee machines, and com ortable chairs; you panies invested in the fundamental aspects of train 10. Managers ignore best practices and lessons includes two who are real experts (the Chief will create an environment where people can focus transportation-tracks and depots. Likewise in soft- learned. Programmer and the Language Lawyer). Having too on their work and forget the rest of the world ware, more "advanced" technologies are far less crit- Given this information, what can we do to get many stars creates ego issues and distractions, while Once you have a team with a productive office call to improving practice than embracing whatI be- s off to a successful start? not having enough can leave the team struggling space, you need the proper equipment. Do not for lieve are the five essential factors to managing a with small problems. any reason scrimp on equipment. The difference be successful software project: Set realistic objectives and expectations- The rest of the team should be good, solid de- tween state-of-the-art machines and adequate de- 1. Start on the right foot. or everyone velopers with compatible personalities and work velopment systems is less than $ 1,000. You will prob- 2. Maintain momentum. The first objective in getting a project off to a habits. The more advanced team members can step ably spend at least $ 100,000 per year to keep a good 3. Track progress. good start is to get everyone on the same wave- ahead into uncharted waters, develop the most crit- developer, including salary. bonuses, benefits, 4. Make smart decisions. length. Management, users, developers, and ical algorithms and applications, and provide training, and other related expenses. That 5. Institutionalize post-mortem analyses. designers must all have realistic expectations. In technical mentoring to the rest of the team. $1,000 amortized over two years represents May/ June 1909 IEEE Software 20 IEEE Software Mar/June 1989 Authorized licensed use limited to: University of the C in August 21,2023 at 21:16:13 UTC from TEEE Xplore. Restrictions apply. Authorized licensed use limited to: University of the Cumberlands. Down August 21,2023 at 21:16:13 UTC from IEEE Xplore. RestricPage 4 of 6 FOCUS FOCUS than 1/2 percent of the employee cost. Quality fair, these experiences will contribute to the team's protocol. Bad call. Always use commercial libraries Finally, your team needs tools. Get good, proven You cannot go back and add quality. By the time cohesiveness and allow them to rebuild momen- when available, and never try to create a new com- tools from stable companies. Nothing will derail a pro- you figure out you have a quality problem, it is prob tum quickly. munications protocol. At best, it will cost you a for- ject faster than using unsupported tools. The team ably too late to fix it. Establish procedures and ex- tune. At worst, it will sink your project also needs training on those tools; losing files and pectations for high levels of quality before any other People also consistently make bad decisions in folders from ignorance and inexperience is painful development begins and hire developers proven to TRACK PROGRESS selecting technologies. For example, how many peo- and costly. The term tool does not just mean com- develop high-quality code. Have the developers par- ple chose to develop applications for the Next plat piler. You also need analysis and design, configura- ticipate in regular peer-level code reviews and ex- Consider the intangible nature of software com- form? Most never finished their applications before tion management, testing, back-up management, ternal reviews. pared to traditional brick-and-mortar construction. that platform went away. When you pick a funda document production, graphics manipulation, and Invariably, when a project is cruising along, every- Construction results in a physical manifestation of mental technology, whether a database engine, op- troubleshooting tools. This is, however, an area where body is excited, the status reports look great, and a conceptual model-the blueprint becomes a erating system, or communications protocol, you going first-class does not necessarily mean spending the GUI is awesome, everything goes wrong. There building that people can touch and see. They can must do a business and a technical analysis. If the he most money. Shop carefully, review a lot of op- may be a bad test report, a failed demo, or a small also touch and see all of the little pieces as they are technology isn't catching market share and if a tions, and involve the entire team in the decision. change request from the customer that becomes healthy company doesn't support it, the pebble that starts an avalanche. You fix one bug, you are building your project on a or make one change, and cause two more. Suddenly, If you don't take time to figure out what sandy foundation. MAINTAIN THE MOMENTUM the development team that was making fantastic happened during a project, both the good Because your foresight is fallible progress is mired in repairing and modifying code and the bad, you're doomed to repeat it. use your design to insulate yourself By now, you have your development team en- that has been in the bank for months. from the underlying technology ergized with strong co-workers, a great working Encapsulate the interface to new or environment, and some high-end hardware. Management being nailed, welded, glued, or screwed to the niche technologies as much as possible. Think about Congratulations, you have momentum. The next Manage your product more than your personnel. framework during construction. Software develop- which technologies will be prone to change over critical factor is maintaining and increasing this After all, the product is what you are selling So, if your ment begins as a conceptual model and results in your product's lifetime and design your application momentum. Building momentum initially is easy. corporate culture can handle it, don't worry about an application, so there is no physical manifestation to insulate-to a practical level-your code from but rebuilding it is dreadfully difficult. Momentum dress codes or fixed work hours. Relax and let people of software that can be touched and measured, es- those changes. changes often during the course of a develop- deliver things at the last minute. Then critique their pecially during construction. You will have many opportunities to make good ment effort. These changes add A large problem in managing software develop- decisions as you negotiate the customer's require up quickly, so it is crucial to Project leaders often avoid confronting ment is figuring where you are in your schedule. ments. Strive to move the requirements from the quickly offset the negative shifts How complete is a module? How long will it take to complicated, "never been done before" category to with positive ones. individuals and merely "fix" a problem finish modules X, Y, and Z? These are hard questions the "been there, done that" category. Often, users You should focus on three key by setting arbitrary team rules. to answer, but they must be addressed If you don't request things that are marginally valuable without items to maintain or rebuild team know where you are in relation to the schedule, you understanding the complexity. Explain the ramifi- momentum: cannot adjust and tweak to bring things back on cations of complicated requirements and require * Attrition-keep it low. products. If the products are not acceptal track. Many methodologies exist for tracking ments changes in terms of cost and schedule. Help * Quality-monitor it early on and establish an start working with the individuals to improve their progress; select one at the right level of detail for them help you. expectation of excellence. products. The goal here is to not make individual is- your effort, and use it religiously. * Management-manage the product more sues team problems. Just because one or two peo- than the people. ple like to come in at 10:00 a.m. and work until 5:00 POST-MORTEM ANALYSIS p.m., abusing the flexibility you give, doesn't mean MAKE SMART DECISIONS Attrition you should dampen the ironment for the whole Few companies institutionalize a process for Attrition is a constant problem in the software in- team. Too often, project leads avoid confronting the Making smart decisions often separates suc- learning from their mistakes. If you do not take time dustry. It can spell disaster for a mid-stream software individuals and merely "fix" the problem by setting cessful project leaders from failures. It shouldn't be to figure out what happened during a project, both project, because replacement personnel must arbitrary team rules. Soon, everyone is griping about hard to identify a bad decision before you make it. the good and the bad, you are doomed to repeat it. quickly get up to speed on software that is not com- deviant co-workers and the strict management. Choosing to rewrite a few of Microsoft's dynamically What can you learn from a post-mortem analy plete, not tested, and probably not well-docu- Those are the sounds of momentum slipping away. linked libraries to accommodate your design sis? First, you learn why your schedule estimates mented yet. A tremendous amount of knowledge Roll a few of these decisions together, and the team choices, for example, is a poor decision. Yet I have were off. Compensating for those factors in the next walks out the door with the person leaving, and is soon focused more on avoiding the rules or tattling seen at least four major projects attempt such in- project will dramatically improve your estimating those left behind have a scapegoat for every prob- on offenders than on producing a quality product. sanity. If your application needs to communicate techniques. A post-mortem will also help you de- lem from then on. Also, in this tight labor market. When you do have a legitimate personnel prob- across a serial connection, do you buy a commercial velop a profile for how your team and company de- the lag time between when a person quits and lem, deal with it quickly. If you must let someone library of communications routines or develop your velop software systems. Most companies and teams when a replacement is hired can wreak havoc with go, do it quickly and then meet with your team to own from scratch? If you build it from scratch, you have personalities that strongly impact the d even the most pessimistic schedules. explain what happened. As long as you are being can then implement your own personally designed opment cycle. As you go through post-mo May/ June 1909 IEEE Software 21 22 IEEE Software May/June 1909 Authorized licensed use limited to: University of the C . Downloaded on August 21,2023 at 21:16:13 UTC from TEEE Xplore. Restrictions apply. Authorized licensed use limited to: University of the Cumberlands. Downloaded on August 21,2023 at 21:16:13 UTC from IEEE Xplore. RestricPage 6 of 6 FOCUS analyses, these personalities emerge as patterns domain. However, this is not an exhaustive list- rather than as isolated incidents. Knowing the pat- many other factors influence the successful man- terns allows you to circumvent or at least schedule agement of a software development effort. But if or them on your next project. you master these five, you greatly increase the odds In his book Managing Software Development of completing your project on time and within bud- Projects, Neal Whitten offers six steps for executing get. Just as important, you increase your chances of a post-mortem review of a project:" actually delivering something your users want * * Declare the intent: Announce at the beginning of the project that you will hold the review. Also define what topics will be addressed, and set the REFERENCES procedures. . R. Whiting, "News Front: Development in Disarray," Software * Select the participants: Choose representa- Magazine, Sept. 1993, p. 20. 2. J. Martin and C. Mcclure, Structured Techniques for Computing, tives from each major group associated with the pro- Prentice Hall, Upper Saddle River, N.J, 1988. ject. To ensure an objective review, management T. Field, "When BAD Things Happen to GOOD Projects," CIO, 15 should not participate directly. Oct. 1997. pp. 55-62 * Prepare the review: After the project is com- . F.P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Addison Wesley Longman, Reading, Mass, 199 plete, assign review participants to gather data. This 5. N. Whitten, Managing Software Develop tware Development Projects, John should include metrics, staffing, inter- and intra- Wiley & Sons, New York, 1996. group communications, quality, and process. . R. Aguayo, Or, Deming: The American Who Taught the Japanese About Quality, Fireside Books, New York, 1990. * Conduct the review: The actual review should not require more than a few days of meetings. All participants should start by presenting their find- ings and experiences with the project. Next, the group prepares two lists: things that went right and things that went wrong Participants can then begin About the Author to work on what went wrong to develop solutions. * Present the results: The participants should John S. Reel is the chief technology offi- present the results to the development team and Data Systems, an informa executive leadership. tion and computer network- * Adopt the recommendations: The company ing company. He is a co-inventor of patented COMSEC technology. He must implement the recommendations on upcom- received a BS in computer science from ng projects. Without this follow-through, the the University of Texas at Tyler and a Pho process yields a marginal benefit. in computer science from Century University. He also worked for the US Department of D The premise and benefit of performing post- in systems support, software development, and management. mortem analyses are validated by the process im- He is a member of the IEEE, the IEEE Computer Society, provement movement inspired by W. Edwards Information Systems Security Association, and the Armed Forces Communications and Electronics Association. Deming during the late 1980s and early 1990s. He suggests objectively measuring a given process and using those measurements to eval- uate the influence of changes to the processes Only by measuring a system and analyzing those incremental measurements can you truly improve the system. Guess what? Your company's software methods and habits for developing software constitute a sys- tem. It is far less defined than an assembly line, but it is still a system. The post-mortem analysis allows you to modify that system for the next "production run." hese five critical factors hold true regardless of the design and development methodology. Readers may contact Reel at $615 Gin Road, Marion, Texas the implementation language, or the application 78124; 0-mail jreeletds.com. May/ June 1909 -IEEE Software 23 Authorized licensed use limited to: University of the Cumberlands. Downloaded on August 21,2023 at 21:16:13 UTC from TEEE Xplore. Restrictions apply