Monday, November 22, 2004
[PM]When to kill a development project
When to kill a development project
By Scott Withrow, Special to CNETAsia | Thursday, November 18 2004 6:29 PM
A widely accepted actuality in project management circles is that up to 50 percent of application development projects fail. Numerous industry surveys and a wealth of media attention, which support this statistic, all too often highlight the negative aspects of large and costly project terminations. In extreme cases, project failures can have a substantial impact on an organization's bottom line. Therefore, all application development managers should be able to recognize and react to troubled projects.
Warning signs
It's often difficult to perceive when an application project is in trouble. Project managers, whose primary objective is a successful project delivery, are frequently reluctant to report project issues as "show stoppers."
Project managers are often too close to project issues to see the bigger picture, namely the impact issues may have on the organization as a whole. Sometimes it's not one large issue, but rather the culmination of several small issues, that will derail a project. Other times, it may not be the project at all, but rather a priority change in the business environment, that will lead to a project's termination.
The application development manager routinely follows up with project leads to ensure that they're meeting project timelines and deliverables. However, application development managers should also periodically revisit a project's scope to ensure project goals remain inline with the business strategy and vision. This periodic review is often a good time to rectify any misconceptions or invalid assumptions that your team might make early in the project planning stages.
Other warning signs that may indicate a project is in trouble include: poor team morale, reduction in productivity, resource "disengagement," excessive planned costs or resources, customer or management apathy, and loss of critical personnel.
Making the call
Once you determine that the project is no longer a priority, termination planning and execution should proceed without hesitation. Any shutdown decision should include input and agreement among business and IT sponsors, the steering committee, and perhaps executive management.
Shutdown planning should include a quick legal and/or compliance review, especially if there are external vendors to consider. Planning should also review project deliverables to see what the organization can salvage or utilize.
Another consideration is how to explain the reason for a project's termination in a way that is sensitive to the staff's morale. You may want to refer to the organization's corporate communications area.
Planning should also include resource reassignments and, if necessary, force reductions. This is an area for which you'll want to call upon the HR department to provide expertise and assistance. Finally, perform a project post mortem to extract thorough information about what went wrong. Treat this as an opportunity to learn valuable lessons.
Scott Withrow has more than 20 years of IT experience, including IT management, Web development management, and internal consulting application analysis.
By Scott Withrow, Special to CNETAsia | Thursday, November 18 2004 6:29 PM
A widely accepted actuality in project management circles is that up to 50 percent of application development projects fail. Numerous industry surveys and a wealth of media attention, which support this statistic, all too often highlight the negative aspects of large and costly project terminations. In extreme cases, project failures can have a substantial impact on an organization's bottom line. Therefore, all application development managers should be able to recognize and react to troubled projects.
Warning signs
It's often difficult to perceive when an application project is in trouble. Project managers, whose primary objective is a successful project delivery, are frequently reluctant to report project issues as "show stoppers."
Project managers are often too close to project issues to see the bigger picture, namely the impact issues may have on the organization as a whole. Sometimes it's not one large issue, but rather the culmination of several small issues, that will derail a project. Other times, it may not be the project at all, but rather a priority change in the business environment, that will lead to a project's termination.
The application development manager routinely follows up with project leads to ensure that they're meeting project timelines and deliverables. However, application development managers should also periodically revisit a project's scope to ensure project goals remain inline with the business strategy and vision. This periodic review is often a good time to rectify any misconceptions or invalid assumptions that your team might make early in the project planning stages.
Other warning signs that may indicate a project is in trouble include: poor team morale, reduction in productivity, resource "disengagement," excessive planned costs or resources, customer or management apathy, and loss of critical personnel.
Making the call
Once you determine that the project is no longer a priority, termination planning and execution should proceed without hesitation. Any shutdown decision should include input and agreement among business and IT sponsors, the steering committee, and perhaps executive management.
Shutdown planning should include a quick legal and/or compliance review, especially if there are external vendors to consider. Planning should also review project deliverables to see what the organization can salvage or utilize.
Another consideration is how to explain the reason for a project's termination in a way that is sensitive to the staff's morale. You may want to refer to the organization's corporate communications area.
Planning should also include resource reassignments and, if necessary, force reductions. This is an area for which you'll want to call upon the HR department to provide expertise and assistance. Finally, perform a project post mortem to extract thorough information about what went wrong. Treat this as an opportunity to learn valuable lessons.
Scott Withrow has more than 20 years of IT experience, including IT management, Web development management, and internal consulting application analysis.
# posted by MiDBA @ 11/22/2004 02:31:00 PM 
