Wednesday, October 29, 2008

Identify the IT Project Mistakes

We can find the classic mistakes happened from people, process, product, to technology. The mistakes are identified and categorized below.

1) People: although IT talent pool is not so scarce than before, how to make IT people work sufficiently and productively is still a big issue especially in a project with large scope. The working atmosphere in the team apparently brings out the workers relationship issue. One of the teammates is isolated from others and bad communication between subordinates and project manager while project manager cannot solve the personnel problem in time. Later on, the teammates started complaining Mike because he failed to deal with the problem worker, who is less likely cooperating with others. Moreover, it raises the untrusted perception to his teammates. It eventually resulted in a delaying project later on and catalyzed a following mistake- thinking that to add workforce in a late project can speed up the projects. However, it is usually hard to reach the goal in that way. Moreover, when a project is far behind schedule, Mike cut the testing time and eliminate design and code reviews, and just performance a minimal testing. He also cut the training time too. Stacy complained that would not give QA enough time to test the software. It is not a good risk management because shortcutting just one day of quality assurance early in a project is likely to cost 3 to 10 days downstream. On the other hand, in the beginning, although Mike has had the support from higher management, he seems not having a good stakeholders’ communication plan to avoid the further political changes or some stakeholders abandon the project in midstream. Along with the bad communication, Mike also failed to communicate with his teammates either while the project was delayed by the reasons above. It is the nature tendency that people feel frustrated while a project keeps delaying the releasing time. Therefore, undermined motivation syndrome occurred within the team as well as weak personnel.

2) Process: there is a significant time constraint here while the executive committee shrinks the schedule from 12 months to 6 months. On the top of that, Mike did not communicate with them and tell them the necessary of appropriate time to complete the project and make sure that the quality control is performed in a reasonable level. As a project manager, Mike underestimated the resource requirement in terms of the amount of code lines, development time, workforce, and the capability of his personnel. Although Mike was trying to solve the problem by changing contractors, it eventually leaded to another uncertainty and made the project involved other potential risks that may not take into account in the beginning. The lack of setting the project boundary first resulted in an ambiguous project scope and while the teammates were keen to try out the emerging technology, Mike didn’t conduct a comprehensive analysis about its cost and effectiveness, leading a potential problem in product side.

3) Product: the automation insurance program is initially an internal program that aims at providing a sufficient operation towards its clients. As time went by, it seemed like changing the scope to a broaden objective. It resulted in an unnecessary product size and characteristic on the front end. The final product was determined to consist of about 40,00 nonblank lines of code in C++.


4) Technology: the team overestimated the saving from new tools and advanced coding language while Carl proposed C++ and object-oriented design, wishing to shorten the development time but ignore the fact that whether it can be compatible with legacy system since the committee were asking them to convert the existing data into new system. Mike thought that sounds good because a new report-building tool that was supposed to cut development time in half.


As we learn from the class, the mistakes tend to be people or process-related, as opposed to product or technology- related. Indeed, technology is a tool to facilitate human operation, but the main element to operate the system to carry out the project is tied with personnel and management ability of its project manager, which is in light of the importance of a good IT project management.

------------------------
reference:
i. Jone, op.cit.1994
ii. MIS Quarterly Executive VOL. 6 NO. 2 / June 2007 77

No comments: