1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

Typical risks that will encounter during IT software development are related to both technical issues as well people who are working for the project. According to personal experience of the consultants and IT professionals interviewed. Weve found that there are Ten Universal Risks to Software Projects. They are: User Involvement: If the users are not intimately involved in planning the project, they may add requirements or change specifications later in the project, which causes time delays and cost increases to your project. Executive Support: Executive should make sure you know who your project sponsor is and make sure that the sponsor knows what it means to be the sponsor. When starting your project, during the earliest phases, make sure the project sponsor knows they are the sponsor and what that means to you as the project manager. Requirements Inflation: As we stated above, not involving the users is one of the biggest problems found in IT projects. This causes requirements inflation because the users begin to see things in the project. A requirements lock down is not practical so you need to document every requested change and require justification for any additional costs or time the change will cause. Schedule flaws: Schedule flaws may originate from many sources like lack of a thorough understanding or the project deliverables and the work involved, low estimates on the work or unrealistic estimates based on meeting an unrealistic end date. But the biggest reason why schedules tend to be flawed is that the project is planned assuming that all will take the most optimistic path possible. Unrealistic expectations: Expectations are the sort of things that keep changing and growing if left un-managed. Managing expectations as if they may impose a risk to the project will improve the projects success and ensure that the deliverables do truly meet expectations. Staff Turnover: If staff changes are likely, prepare contingency plans, begin a cross training plan prior to actually losing the staff member and add it to the risk management plan and state that significant staff changes will impact both the budget and schedule. Because movement within an organization can cause havoc on a project as well. Project Management: If they refuse to involve the users, issues are not resolved, they dont want to bother executive management, or they develop the schedule and project plan mostly by themselves, they may be introducing risk into the project. Specification Breakdown: If the specifications are not developed correctly and too many short cuts were used, the development team cant understand the specifications, even users cant understand how their requirements tied in to the specifications. Technology and uncertainty: If you are trying to install a new platform, using new software, with new interfaces to perform new functions the level of uncertainty (RISK) goes way up. Cost, schedule and quality estimates all have to be adjusted accordingly. Not knowing what is at stake: If the project was failing and things were running out of control. Then there will be no clear understanding of what is really at stake, which results in a confused state of what to do?

Technical risks: Technology Age describes whether the technology proposed is New, Old, or Current. The newer the technology, the higher the risk. One might also consider the availability, quality, stability of the infrastructure, such as databases, data administration, languages and tools, networks, etc. Technical risks generally leads to failure of functionality and performance. Causes of technical risks are:

Continuous changing requirements No advanced technology available or the existing technology is in initial stages. Product is complex to implement. Difficult project modules integration.

Risk can be reduced by using Current instead of New technologies. Or projects can be delayed until the technology is proven. (This depends on whether your organization wants a risky R&D project or a less risky operational system.) The major influence lies in the development process you choose and not the technologies being used. In waterfall model, the problem is that developing software is inherently unpredictable and this type of process does not cope effectively with change. The result is that this approach to developing software almost always fails to mitigate risk. An iterative approach will continuously reduce project risk from the outset.
Because at the end of each development cycle, the software should be demonstrated to the users to obtain feedback on its functionality and suitability.

Communication is paramount within the team and more importantly with your users and sponsors. This has to be on a regular basis, daily with the team, and at least weekly with the users and sponsors. Your end goal should be to make all these groups part of the project team. Iterative development will greatly increase communication with the users. Because without everybody working together you haven't got a team and
the project will fail.

The risks are associated with planning the project and including the PEOPLE involved in your project. Many are communications and human resources issues. Most of these risks are associated with the technology, methodology or information which we usually think of in IT projects or software development.