Name of the course : ITEC580 - Projects and Risk Management Name : Meisam Siamidoudaran

1. Name of the course : ITEC580 - Projects and RiskManagement Name : Meisam Siamidoudaran Chapter 17 Implementation

2. INTRODUCTION If you look at books on systems analysis and IT, you’ll find little said aboutimplementation and maintenance. Yet these are important activities. Implementationis where the rubber meets the road, so to speak. This is an area of highrisk and peril. You could do all of the previous work with good quality, followstandards, and then discover that there are new issues at the end. Users arereally going to resist change since the project that was over the horizon is nowin their face.

3. USERS WHO REFUSE TO ACCEPT RESPONSIBILITY Discussion User managers signed off on the requirements. Users participated intesting. They were trained. Now you are asking that they accept the system andplace it into use. There are a number of political reasons why they refuse totake it: • The users have to change their process. • They do get paid more money for this extra work. • They have to change their exceptions. • The king and queen bees fear they will lose power. • The users are fearful of taking on the responsibility.

4. Impact If the users do not accept responsibility, what is IT going to do? How willIT respond? Often, they react in an inappropriate way. In a few cases, they maywalk away from the work. This is rare. More often, they take the position thatthey have done their part. Detection You can detect the problem if users start to raise new questions and issues.They may advance new requirements. They indicate that they are too busy. Actions and Prevention Begin with anticipating and planning for this. If it does not happen, you willhave something rare — a pleasant surprise.

5. USERS BEING UNAVAILABLE TO PARTICIPATE INTHE IMPLEMENTATION Discussion The users are obviously busy doing their normal work. They are unavailablebecause this normal work is receiving a higher ranking. Impact If the users are unavailable, then the implementation may have to be deferred.After one deferral, the users give new reasons why they cannot participate.

6. Detection Talk to some of the supervisors and middle-level managers. Ask them whatthey hear from their people. Another tip is to establish a good working relationshipwith junior users. Actions and Prevention As with every issue in this chapter, anticipate this. Plan when users will beavailable. Find out what is happening in the departments. When you are doing the turnover, minimize, if you can, the number of peoplethat will be using the system in production at first.

7. LAST-MINUTE REQUIREMENT CHANGES Discussion How can these come up? You gathered requirements months ago. The userssigned off. Why are they doing this now? For the bulleted reasons given withthe first issue. Fear of change is a major factor. If they can add more requirements,they may delay the implementation. Then they can add more. Maybe thenew system will disappear and go away.

8. Impact New requirements mean more IT work and a delay in implementation.However, the schedule was set and the schedules of other projects depend onthe completion of this one. The impact is cascading delays across multipleprojects. Detection Earlier, we talked about changing requirements. We gave some questionsthat probe why the change occurs now and what it means. These questions focuson what is different, why it was not detected earlier, and the effects if thesechanges are not made.

9. Actions and Prevention Head this off from the start. Circulate the changing requirements questions,and tell the users that the questions must be answered before there is any change.Next, during the project, the IT project leader should visit the users often to seeif anything new has come up.

10. LINGERING ISSUES Discussion We have seen no implementation that is 100%. It is like building a house.Some things will still require fixing after the new occupants have moved in. Soit is more than likely that there will be lingering issues. Here are a few examples of lingering issues: • Additional screens or reports are needed. • Exceptions remain to be addressed. • Some shadow systems remain. • New work has cropped up that has to be handled by exceptions

11. Impact If the IT staff members have to deal with these issues before implementation,delay will result, often the cascading delay mentioned earlier. This is a majorproblem and creates political problems between IT and the users. Detection Keep track of the issues, as was discussed in Chapters 2 and 3. In that way,you can see if some issues are not likely to be resolved. Knowing this you canplan ahead for how the users could cope without the solution and still implementthe system.

12. Actions and Prevention Follow the steps in the preceding section. Then consider lingering issues asan opportunity, not a problem. What is this? Lingering issues give IT a chanceto visit the users. They can see how they are using the new system. They canobserve the fit of the new process with the new system. They may discover otherissues.

13. RESOLVED ISSUES THAT BECOME UNRESOLVED Discussion This is a variation of several of the preceding issues. However, it happenssufficiently often that it deserves individual attention. Here are some of thereasons why this occurs: • The users lost out on some issues. • The solution of the issues before was not complete or created someadditional problems. Impact Having to revisit issues tests the patience of the project leader. “Here we goagain.” If the issue is treated as a new issue, then the problems discussed earlierin this chapter happen, as do the negative impacts.

14. Detection When any “new” issue is brought up, do not accept it as a new issue. Look,you have handled many issues during the project. It is highly likely that it isreally an old issue in new clothes. So what do you do? Assume the problem isan old issue that has been recast, and treat it as such. Actions and Prevention Adhere to the issues tracking in Part I of this book. Take any “new” issueand see if you and the team can warp the issue into a version or variation of anold one.

15. USERS WHO RESIST CHANGE DURINGTHE IMPLEMENTATION Discussion This is an umbrella issue under which some of the other issues in this chapterfit. As was said before, you want to anticipate and expect that there will beresistance, for all of the reasons discussed before. Impact The general effect of resistance is to slow things down when concerns areaddressed. You have to ameliorate the fear factor. If you attempt to paper thisover or ignore it, it will come back, most of the time with a vengeance.

16. Detection You can detect the problem by seeing how people interact with the projectleader and IT as implementation draws near. The users who do not want thechange are not as open. They are more reserved and may not be friendly. Theymay be hostile. Actions Involvement of more users along the way is a good idea. Another is to definethe new process during requirements. This will give stability to requirements.

17. USERS WHO CONTINUE TO WORK WITHTHE OLD SYSTEM Discussion The new system and process are implemented. IT declares another success.The IT staff members are reassigned. Impact If the users start to use both the old and new processes, their effectivenessand that of department employees suffers. The benefits that were estimated andthought to have been attained begin to evaporate.

18. Detection You can revisit the users and department and find out how the work is beingdone. Rather than carry out interviews, just observe. See what they do. The firsttime you visit, they notice you and will behave differently, so visit them severaltimes to find the truth. Actions and Prevention A basic problem is that the life cycle ends when the system is installed. Manyorganizations have no provision for what to do after that. This plays right intothe hands of the king and queen bees.

19. PROBLEMS WITH THE DATA DISCOVERED DURINGDATA CONVERSION Discussion Data conversion is a curse, since there can be unanticipated problems withdata quality and completeness. What makes the situation worse is that dataconversion may be treated as a routine part of the project. It is not. It has substantialrisk. Impact If the data conversion is delayed, then the new system cannot go live. But itgets worse. Fixing the data conversion may require extensive manual entry ormore programming, leading to more delays to an already tight schedule.

20. Detection If data conversion is not treated seriously at the start and given resourcesand attention, then you will likely see this problem later. The earlier that youuncover data problems, the more time you have to fi x them. And you preventan unpleasant surprise later. Actions and Prevention The forward planning is one step. Another step is to actively involve theusers in the data analysis. We don’t mean one user; we mean several users atdifferent levels.

21. USER MANAGEMENT THAT IS UNWILLING TOENFORCE TURNOVER TO THE NEW PROCESS Discussion This is particularly true with middle-level management. They receive a lotof heat from their employees about disruption and change. Impact If the employees sense that their management has reservations and is waffling on the turnover, their fears have been realized.

22. Detection Talk to middle-level managers. Find out if they have any questions. Ask themwhat they have heard. Go to the employee level and try to uncover the individualswho have raised the problems and concerns. Actions and Prevention You want to nip this problem in the bud — early. You also want to head itoff if you can. Here is what we do. Raise the issue as a potential problem earlier,before implementation, with user management. Show them some of the issuespresented in this chapter. Raise their level of awareness. They and you are nowbetter prepared to cope.

23. INADEQUATE USER TESTING Discussion A funny thing happened at a major airline. A major airline manufacturerproduced a new toilet for one model. They gave it to their customers to test out.The thinking was that the customer could get involved in testing. The new toiletwas placed in the middle of an open floor of customer service employees. Therewas plumbing and partitions installed. The employees were told to test it. Theywere given evaluation forms.What happened? The employees did not want to use it. However, they knewthat their management would be upset if they did not fill out the forms. So theydecided, as a group, to fill out the forms without any testing. While they mentioneda few problems, the toilet was a success.

24. Impact The worse direct impact is failure in early operation. However, less dramaticthings can occur. The problems do not come up all at once. They occur one byone or in small groups over time. The users begin to lose confidence in thesystem. Detection Here are some useful questions: • How early in the project did the users get to do testing? • How were the users trained to test? • Is there a systematic approach to organizing the testing? • How many users are involved in the testing? Actions and Prevention The earlier that testing is planned, the better. The more users who areinvolved, the better.

25. CONCLUSIONS Many of the issues in implementation had their roots, and could have beenprevented, much earlier. If not prevented, at least they could have been handledmore rapidly and effectively during implementation. People doing the projectwork may be getting tired, but when the implementation kicks off, the fun isjust beginning. So are the games some people play.

26. "Thank you for your attention"