Subscribe by Email

Your email:

Follow Me

Current Articles | RSS Feed RSS Feed

Top 5 Risks for IT Projects

Do you manage IT or software development projects? Have you seen a pattern of risks that appears in almost every project? Here are my top 5 risks that IT projects may experience:

1. Other new projects (perhaps “higher priority”) may take resources away.

2. Systems/infrastructure upgrades (either planned or unplanned) may occur in the middle of your project. Your project may be delayed by days or even weeks.

3. There may be unanticipated requirement changes. The scope may change, unplanned/new requirements may get added or current requirements modified—all of which results in either additional work or rework.

4. Detailed impact analysis may bring up something new that may push the project dates. Even though the requirements may not change, these new findings can cause delays.

5. Coding may take longer than anticipated. Estimates are proven wrong most of the times. In fact, the development teams may take much longer than what was expected.

So does this list match with yours? My guess is that it’s pretty similar.

Sometimes I ask myself a question: If a risk appears in most projects, then is it truly a “risk” or is it more a product of the skills or the culture of the organization. Let us consider the 2nd risk from the list above – “Unforeseen software upgrades may delay the project.”

Now, if this winds up being a risk for every project, does this not go back to poor planning and/or problems with intra-departmental communication? Either the department responsible for software upgrades is lacking the skills to do the proper planning or there is no culture of planning (things happens as they come along—along the lines of “life happens”). Or perhaps they have very detailed plans but plans are never communicated to the project teams? Or it’s a combination of both.

Do you think finding a resolution to this kind of recurring risk is within the scope of work for a project manager? If you are project manager who has faced this situation (listing the same risk over and over again on different projects), what would you do?


You should also mention that the user or client needs to be involved with the design and the aims or deliverables need to be explicitly agreed with them so that scope creep is lowered. However you shouldn't remove to option for changes later but any changes need to be agreed upon by the client so that more resources can be allocated instead of attempting to improve the project with the same amount of resources you started with which could mean you have no time to finish the project, or use more resources than you have. 
Also you could mention that the executives of the company should be very supportive of the project to ensure that resources are properly allocated and the staff are properly motivated.
Posted @ Thursday, January 17, 2013 8:00 AM by Thomas H
Post Comment
Website (optional)

Allowed tags: <a> link, <b> bold, <i> italics