How to identify problems with an IT project before it’s too late
Too often, problems with IT projects go unrecognized until it becomes impossible to ignore them, such as when the project budget has grown wildly overblown or the schedule is careening off track.
Identifying potential problems with IT projects -- problems simmering below the surface of your pristine project plan -- may seem impossible. After all, who has time to step back and assess the status of a project with so many moving parts when the schedule that was established for it is already overly aggressive?
In fact, there's an easy way to identify problems with projects before they get out of hand. Rob Prinzo, CEO of project management training and consulting firm The Prinzo Group, recommends asking project team members for their take on the status of the project.
"Interview key participants to find out the business drivers [for the project], the political environment, organizational barriers, what's worked well in the past," says Prinzo. "They'll tell you what's wrong with the project."
Asking project team members about potential problems is one step in a process Prinzo uses to gauge the "health" of IT projects and also to identify gaps in requirements, staffing needs, end-user training plans, and change management initiatives that might threaten the success of a systems implementation, software upgrade, or new hardware rollout. Other steps include reviewing project documentation to make sure it's complete and sharing your findings with project stakeholders so that you can quickly solve problems.
The red flag of incomplete documentation can indicate that a part of the project hasn't been thought through, says Prinzo. For example, project documentation that doesn't explain how end-users will be trained on a new software application may lead to users getting short shrift on training, which in turn could hamper adoption of the new software.
Similarly, ill-defined requirements -- or differences between users' requirements and what IT thinks that users need -- can lead to software that doesn't meet the organization's needs. A third example: If a needs assessment for a new system hasn't been documented, executive and user support for the project could wane.
IT departments working to complete the projects they had postponed during the recession would be wise to conduct check-ins on their projects to ensure they can finish them on time and on budget with the limited staff they have available. The sooner -- and more regularly -- they do it during the project's lifecycle, the better off they'll be, says Prinzo.
"People say this [process] is added overhead, but if you have a methodology to follow, it can be a very succinct process," says Prinzo. "Using this project assurance methodology throughout the project, you can identify gaps before they get too big and head off failure at the pass. When I spend time on the front end with project teams to go through a risk assessment and gap analysis, the outcome is that when we get to the development and testing phase, there isn't a need for these assessments any more, and we're looking at how can we make this go live more successfully."
(Source: infoworld.com)
