Presented by : Soudabeh Gorjinezhad Instructor : Prof. Mustafa İlkan April 2013

1. Development Presented by : SoudabehGorjinezhad Instructor : Prof. Mustafa İlkan April 2013

2. OUTLINE • Overreliance on One Person • Departure of a Key Person • Development Performed Ad Hoc Without Adequate Design • Lack of Emphasis on Testing • Inadequate Tools • Developers Who Do Not Share Knowledge • Lack of In-depth Review of Work • Users Who Regularly Contact Programmers Directly • Lack of Teamwork Among Developers • Developers Who Cannot Agree on the Details of the Technical Approach • Few Guidelines For Doing the Work • Lack of Applying Past Knowledge and Experience • Developers Who Are Concentrating on the Easy Parts First • Conclusions

3. INTRODUCTION System development has been an area of great interest for IT researchers andmanagers for decades. It is part of the core and roots of IT. Various methodologiesand software tools have come and gone. There was structured programmingand design now gone. Why IT people are interest in system development ? Why have so many techniques emergedand vanished? The answer to the first question is: Importance andIssues. The same is true for the second question.

4. OVERRELIANCE ON ONE PERSON Discussion This is not uncommon across IT. The IT group is small spread . The IT group cannot afford to have multiple people understanding the same things . it is the same In an automobile, dealership some mechanics are trained to dealwith one specific car model or engine. In networks, there may be a single highlytechnical troubleshooter. In applications software, there may be only one programmerwho supports an old system .

5. OVERRELIANCE ON ONE PERSON Impact The impact can start with uneven workloads. If nothing is going on with aparticular application, the specialized person may handle lower-priority work.Next door, in other cubicles, other members of the IT staff are working extra to get the work done . There is the fear that if you put this specialized person to work on somethingelse, he or she will not be able to respond to a production problem. So the ITmanager leaves the person alone.

6. Overreliance on One Person Detection Looking at the allocation of people to jobs and applications, you can detect a problem. You can also view the workload. If the work is falling unevenly on the employees, thenthis is another sign of the problem.

7. OVERRELIANCE ON ONE PERSON Actions and Prevention If IT people want to prevent the problem in the system it will bethere because of the limited resources, range of work to be done, and timepressure. some actions: In the extreme cases, you might consider buying an application to replace that which the programmer is supporting. Another technique is to begin to have the person sharing knowledge. Could the programmer document everything? In our experience, this does notwork. For programmer, it took nine months of pushing the informationout. In many situations,the person sees the knowledge as security and power and will not want toshare it.

8. DEPARTURE OF A KEY PERSON Discussion Suppose that there is a tightproject deadline, and the critical person, user or programmer, bails out. Who is a key person? It is not just someone with special knowledge or skills.It can be someone on whom you have learned to rely because of past performance.

9. DEPARTURE OF A KEY PERSON Impact The work that the person was supposed to do is now undone. The schedule suffers. It will take time and a learning curve for someone new to catch on and catch up. The management may feel that the work is not well managed. This is particularly true among userswho are told that their system will not be delivered on time because of the lossof a key person.

10. DEPARTURE OF A KEY PERSON Detection There are signs that a person may be intending to leave. The individual maybe absent from work to go on interviews. Earlier, he or she may be showingless interest in the work, becoming more detached. The person may not wantto share information as much as previously. You can sometimes detect the problem by what coworkers tell you.

11. DEPARTURE OF A KEY PERSON Actions and Prevention You can take steps to mitigate the damage. One is that any critical personshould not be given tasks that do not deliver milestones or results for weeks ora month or more. If the person leaves before this is done, there could be a majorloss. Another step is to implement joint tasks. That is, two people are assignedto critical tasks, with one in charge. Whatbenefit does this give the IT manager? If two people work together, you aremore likely to get the status of the work. You will also find out more aboutattitudes of the staff members. Another benefit is that you will have some degreeof backup.

12. DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN Discussion Improved development environments are now available. The tools themselvesare improved. Design is simpler since we are often dealing with componentsand object libraries. Today, we have to specify how components and modules will relate. While thegoal of efficiency is somewhat replaced with effectiveness, creating effectivesystems means designing for flexibility and maintainability.

13. DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN Impact If you rush pellmell into development, experience reveals that programmingsometimes has to be redone several times. You find things during the programmingthat cause you to rethink the development.The more you redo something and make changes, the more complex theprograms become. Then they are more difficult to change and enhance later.This can play havoc with the schedule.

14. DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE DESIGN Detection How much effort is going into design? Now, it is possible to begin programming some parts of a system if the design is not yet completed. However, with too much of this, you will see the issue arising.

15. DEVELOPMENT PERFORMED AD HOC WITHOUT ADEQUATE Action and Prevention Design is not what it was years ago. You do not have to spend as much timedesigning the detailed user interface, since most of these are Web based. A good idea is to plan out the work to answer the following question: Whatis the minimum amount of design work necessary? To address this questionyou must give attention to the areas that have the greatest risk. A major fault of designwork in the past has been to focus on routine and easier parts of the design,with the hard parts left to the programmers.

16. LACK OF EMPHASIS ON TESTING Discussion A separate test environment supports a more structured approach to development and helps to support better configuration management practices. Why don’t people, and in particular management, pay more attention to testing? One reason is the schedule.

17. LACK OF EMPHASIS ON TESTING Impact For example: a person using his father’s credit card. He was trying different things withdiscounts. He found a way to combine three discounts to get merchandisefree. He did it and ordered $1,000 worth of goods.There wasno charge. Then he ordered $18,000 worth of merchandise. The same thinghappened. In a chat room he then posted how to do it. Within a week the firmhad received and shipped over $1.5 million in goods. They thought e-businesswas great until they found that they had given the goods away. For oneJapanese computer maker this was a problem. They advertised a new notebookon their Website. Almost immediately, they received many orders. This madethem curious Then theyread their own Website description, maybe some for the first time. Too bad,there were a number of zeros left out of the price in yen. In essence they gaveaway thousands of machines.

18. LACK OF EMPHASIS ON TESTING Detection Rather than look at the testing, consider management’s attitude. Is there a separate testing group? Or is the only testing performed by developers? How are the testers trained, paid, and incentivized? Is there a separate test environment? Answers here can be very revealing. You can also probe the actual testing, but this is often enough for you.

19. LACK OF EMPHASIS ON TESTING Action and prevention There should beseparate testers organized apart from the developers, for separation. Here isanother tip from our experience: Use the children of employees to do testing ofWeb-based software. Give them small gifts for each problem they uncover.Assign the older kids to review the text of the Web pages, with similar incentives.Kids, we have learned, have infinite time and are Sometimes more inventivein finding ways to break the system than adults.

20. INADEQUATE TOOLS Discussion Each technical IT function has its own tools. Here is a sample list. Thesetools may be provided by the manufacturer of the hardware, network hardware,or software. Thethird-party products were originally created to fill holes in tools made availableby the manufacturers. Over time, if the third-party software is successful, thenthe manufacturer may buy the third party or develop and sell their own competingproduct. So the mix of available tools changes over time due to this factorand new releases of current tools.

21. INADEQUATE TOOLS Editors Debuggers Testers Compilers Network monitoring Network management Capacity planning Design documentation Program design aids How can this be today? Aren’t there enough? You can never have sufficient toolsif you are a programmer Things are better but by no means perfect. In what wayscan the tools be inadequate? Several tools might work well individually, butthey do not interfacewith each other well .There are guidelines or best practices on how best to work with the tool . Every tool supports a method. It is possible that two different toolssupport different methods. People are forced to use the two toolsbecause they provide value and there is nothing else on the market.

22. INADEQUATE TOOLS Impact As you know from working around a house, apartment, or car, if you have poor tools, it will take longer to do the work. Inadequacy can lead toadditional, unplanned work. It takes as much or more time to learn how to use the tool effectively as itdoes to do the work.Another impact lies in frequency of use.

23. INADEQUATE TOOLS Detection You should catalog the current state of methods and tools for both internalIT staff and the consultants and IT vendors. The tool supports a method and makes it easier to follow . This, combinedwith improved productivity, provides the management benefit for the methodand the tool.What happens if you have an area with either no method or tool or both? TheIT staff and/or consultants improvise their approach. There is inconsistency.There are three additional elements in the table. Whether guidelines exist inbest practices should be indicated. If no guidelines are available, then theremight be a problem.Without an expert, the IT staff who work with the method and tool can flailaround trying different approaches. This can waste time.The last element is management expectations. Since the other elements ofthe table are technical, you might wonder why this is here. That’s because theIT staff and consultants should know what is expected of them. They can thenattempt to get the best use out of the methods and tools.

24. INADEQUATE TOOLS Actions and Prevention That can reveal where the gaps are. Wherethere is a gap, people tend to invent their own individual solutions. Try toprevent this or act on the problem by filling the gap. Experience shows that youcannot address all of these, since you are not in the tool business.Next, you might reconsider the choice of tools. Maybe another method hasa wider range of aids and tools. The other method is more widely used.

25. DEVELOPERS WHO DO NOT SHARE KNOWLEDGE Discussion Developers or engineers may have taken years to acquiretheir knowledge and experince . Software developershave created their own modules that perform certain functions.We did this as programmers starting with assembler andthen COBOL, C, FORTRAN, Visual Basic, etc. These modules are products ofyour knowledge and creativity. They help you to be more productive and cangive you a competitive advantage.It is not surprising to us that technicalstaff are now willing to share knowledge. If you share how you do things, others could do the same work.The experience and knowledge gives an edge to senior people in many fields.That is a main justification for paying them more than junior people with thesame amount of formal training. That is the same situation for teachers inseminars and classes. A senior person, such as a full professor, has more knowledgeand experience than a junior one. Both can teach out of the same textbooks,but the senior professor adds value through experience and knowledge.

26. DEVELOPERS WHO DO NOT SHARE KNOWLEDGE Impact If management does not value experience and knowledge, then they cannotsee the value of this in the work. They see one person as interchangeable withanother. This can drive the senior people to seek positionswith firms that do value the expertise, knowledge, and experience.While it is understandable and mostly acceptable that complete knowledgesharing is not possible or even desirable, there are many times when somesharing of information is needed in IT. Developers need to share informationwith the people who will do maintenance. If the developers do not share theknowledge, they end up supporting the software and systems in production.Why would people want to do this? Ifthey do maintenance, then they have a long-term job.

27. DEVELOPERS WHO DO NOT SHARE KNOWLEDGE Detection Take a look at the individuals who are providing maintenance, productionsupport, and enhancements. If they are the same ones who did the development,you have observed the issue. Another sign appears if there is a big diffrencein the skill and knowledge levels between junior and senior IT staff. This indicatesthat the senior people are hoarding information. After all, knowledge ispower in this case, informal power.

28. DEVELOPERS WHO DO NOT SHARE KNOWLEDGE Actions and Prevention You cannot force people to share knowledge directly. the senior person may share only a part of theinformation What can you do indirectly? First, you can implement the approach of sharedtasks. This can provide pressure to getthe individual to open up to someone else. A second step is to implement lessons learned meetings.Since they are not being singled out, they are under major political pressureto participate. It will eventually be their turn.A third technique is to reward knowledge sharing. This is rare.

29. LACK OF IN-DEPTH REVIEW OF WORK Discussion The most asset in IT groups is not money it is time. There istoo much to do and too little time. The pressure of time carries across all ITwork. An IT leader may think that since the IT staff members are qualified, it isunnecessary to review their work in detail or depth. If the leader tries to dothis, the individual may take offense, responding, “Don’t you trust me? I saidit was done.” The IT leader may not be technical or have a technical backgroundand thus may be intimidated by a technical review, fearing a loss of respect andesteem if any ignorance is revealed in the review.

30. LACK OF IN-DEPTH REVIEW OF WORK Impact If IT staff members see that there is no in-depth review of their work, theymay be led to the false idea that management does not care about quality justget something done. The problems with quality then appear later. And, if youhave been in IT at all, you know a basic truth The later a quality problem surfaces,the more effort is needed to fix the problem . On the other hand, if you review too much, you take time away from otherpressing matters, such as resolving and addressing issues.

31. LACK OF IN-DEPTH REVIEW OF WORK Detection It is too time consuming to examine the work quality in detail. Turn yourattention to the review of the work. Take a project, any significant project, andfind the milestones associated with tasks that have risk and issues. What reviewswere done?Next, focus on the small projects and non project work. What problems and issues exist for this that are traceable toquality? What surprises have appeared recently? Are these technical? Can they be traced to quality.

32. LACK OF IN-DEPTH REVIEW OF WORK Actions and Prevention Let’s examine how building inspectors conduct reviews. They cannot review everything even in a small house. What do they do? Time is short. They concentrate on where they haveseen problems in the past, testing these areas first. If these are acceptable, thismay end the inspection. If not, then they probe in more depth. They may askthe contractor to explain how they did the work.That is an approach suitable to IT. First, you want to determine in the project. This is where you want to give moreattention.

33. LACK OF IN-DEPTH REVIEW OF WORK Here are some questions to get answered. The answers canhelp you zoom in on specific areas of greatest risk and with the most and severestissues. What problems did they encounter? How did they address the problems? What surprises did they experience? What did they learn from the work? What was the hardest work? What do you do with the other work? Do you just accept it as is? No. Here youcan do what we have done with our children’s schoolwork. There is too muchhomework to review, so you focus on the classes and subjects in which they arethe weakest. This is the test of existence.For work in between existence and a detailed review, This can be a starting point for a detailed review as well.

34. LACK OF TEAMWORK AMONG DEVELOPERS Impact The effect of a lack of teamwork is that IT people work alonefor the most part. Management sees no value in teamwork; some of the IT staffdon’t either. If people areall working in single cubicles separated by high partitions (à la Dilbert), thenthis tends to discourage teamwork. There is no place to get together except ina conference room. But conference rooms have to be reserved and are formeetings.If there is no or little teamwork, the issue of lack of knowledge sharing willappear. Without teamwork,IT management has no backup for a person. This slowsdown the work while a replacement is found. When someone else arrives to dothe work, the person has no one to teach them the essential information quickly.

35. LACK OF TEAMWORK AMONG DEVELOPERS Actions and Prevention Here are the actions we often take. Assign shared tasks, with one person in charge. This will ensureaccountability. Change the physical layout of IT. Implement shared offices to encourageteamwork and knowledge sharing. Implement lessons learned meeting to facilitate teamwork. Reward teamwork as well as individual work.

36. LACK OF TEAMWORK AMONG DEVELOPERS Detection Look at the layout of the IT space. Does it facilitate teamwork? Next,examine the project plans. Are most or all of the tasks assigned to only oneperson? If so, you have the issue. Another thing to observe is the content ofmeetings. If the meetings deal with administrative matters, then there is littleor no teamwork.

37. USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY Discussion When IT gets a maintenance request, it is often handed off to theprogrammer directly. There is no perceived need in doing project management.It is too small. Also, the level of risk is not thought to be high.This work puts the programmer directly in contact with the users. The userslike this because they are not talking to some IT manager or middleman. Theprogrammer has no middleman and can get and give information quickly.At first glance this seems to be a maintenance and operations issue.Many programmers are involved in development and maintenance at the sametime, so the issue can affect their work in development negatively.

38. USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY Impact Experience reveals that once users are put in direct touch with the programmers,they easily calling them directly. Why bother puttingthrough a request for a “small” change? Just pick up that phone or tap out ane-mail and get help directly. It is better than a 911 emergency call. More often than not, the programmer is seatedat his or her desk. No call-waiting. The programmer is now interrupted andmust drop work to handle the call. After the call, it will take some time for theprogrammer to regain the concentration to continue working. This wastes timeand reduces productivity.Programmers often are people who like to please the users . Rodney Dangerfieldsaid, get a “little respect.” So the programmers tend to be very responsive tousers when put in direct contact. They will not ask critical or negative questionssuch as “If we are unable to do it, what will you do?The user has a seemingly innocent and simple request. Just change a screenor report or handle a new exception.

39. USERS WHO REGULARLY CONTACT POGRAMMERS DIRECTLY Detection Here are some questions to answer. What are the programmers working on now? How did they spend their time in the past two weeks? What was the source of the work? How much and what work came from users directly? Once you uncover this, you can find out which users are goingdirectly to the programmers.

40. USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY Actions and Prevention One approach is to go to the users and tell them they have to go throughchannels. Just like an automobile dealership, customers do notgoing directly to the mechanics. Here is ITmanagement again trying to put barriers in the way of getting the work done. If this is not a good idea, what else can you do? First, you should hold ashort meeting on a weekly basis among the IT supervisors and project leadersand allocate the programmers’ and others’ time for the coming week . Thenfollow up during the week.Another step is to talk to the programmers about the agendas and politicsof users . Users sometimes tend to exploit their relationship with individual ITstaff to show that they have informal power. They can get things done for thedepartment that their own management cannot get done. King and queen bees

41. USERS WHO REGULARLY CONTACT PROGRAMMERS DIRECTLY can be expert at this. You want the programmers to realize that they can bemanipulated.Next, appeal to their self-interest. If all the programmers did was respondto users, they would get little done. Their work would not be significant to thebusiness. Their value as employees would be diminished. They are insteadbeing used, abused, and manipulated.

42. LACK OF TEAMWORK AMONG DEVELOPERS Discussion IT does many projects. Projects are things that are supposed to be done bya team. What do the words team and teamwork mean? They mean workingtogether . The problem arises in ITmanagement. IT managers associate teamwork with meetings. However, if themeetings are mainly status meetings, then there is no teamwork. Each persongives his or her status while others in the meeting go mentally asleep until it istheir turn to report.Why does this arise? Managers, especially ones with less experience or thosewho are insecure, want accountability. To them, accountability means the focusis on the individual and his or her performance . The managers may feel that teamworkwill slow the work down. While they may see long-term benefits to teamwork,they are intent on achieving short-term results.

43. LACK OF TEAMWORK AMONG DEVELOPERS Impact The effect of a lack of teamwork is that IT people work alone in the most cases . Management sees no value in teamwork . The work layout and arrangement can reinforce this. If people areall working in single cubicles separated by high partitions (à la Dilbert), thenthis tends to discourage teamwork. There is no place to get together except ina conference room. But conference rooms have to be reserved and are formeetings.If there is no or little teamwork, the issue of lack of knowledge sharing willappear. Without teamwork,IT management has no backup for a person if he or she departs. This slowsdown the work while a replacement is found. When someone else arrives to dothe work, the person has no one to teach them the essential information quickly.

44. LACK OF TEAMWORK AMONG DEVELOPERS Detection Look at the layout of the IT space. Does it facilitate teamwork? Next,examine the project plans. Are most or all of the tasks assigned to only oneperson? If so, you have the issue. Another thing to observe is the content ofmeetings. If the meetings deal with administrative matters, then there is littleor no teamwork.

45. LACK OF TEAMWORK AMONG DEVELOPERS Actions and Prevention We encounter this problem most of the time when we take over an IT groupto turn it around. Here are the actions we often take. Assign shared tasks, with one person in charge. This will ensureaccountability . Change the physical layout of IT. Implement shared offices to encourageteamwork and knowledge sharing. Implement lessons learned meeting to facilitate teamwork . Reward teamwork as well as individual work.

46. DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH Discussion This issue crops up in construction, auto repair, and other fields as well.Technical people come from different experiences and backgrounds. As such,they often have different views on a technical approach.This is actually a good thing an opportunity. It goes bad when the disagreementsare not controlled and continue unabated for days or weeks. Thenit is an issue.

47. DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH Impact One potential impact is that in the short term, work is delayed while peopletry to decide what to do. Often the IT managers do not get involved. Theproblem worsens. For technical staff, it can be very personal and nasty. Over the longer term, we have seen this issue grow to divide the IT staffmembers into warring camps. Each camp adheres to a specific philosophy. Itis difficult to get things done under these conditions.

48. DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH Detection Sometimes you can detect the issue by listening to what people say in free time. Then you can tell ifthe problem is growing when the discussion moves into project meetings.Another idea is to focus on a facet of the technical issue and see how stronglythe staff members react. This will indicate the depth of the disagreement.

49. DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OFTHE TECHNICAL APPROACH Actions and Prevention You have to look at the problem from a management perspective. After youdetermine the source question or issue of the disagreement, you can find the answer What is the impact on the business and business processes of eachalternative This can force the IT staff to talk in businessterms.

50. DEVELOPERS WHO CANNOT AGREE ON THE DETAILS OF THE TECHNICAL APPROACH What is the impact in IT on current work? What is the impact in IT on maintenanceenhancements, and support? What if we continue to do what we are doing now? Is there another option? IT people sometimes have hidden agendas. They may feel that if they win onthe question, they will have easier work, more informal power and so on.