Some projects seem to take on a "life of their own" and are known as runaway, or perpetual, projects. These projects never seem to end. Perpetual projects may result from delays or a scope or MOV that was never clearly defined or agreed upon. Then, the project sponsor (or even the team) may attempt to add on various features or functionality to the system, which results in added time and resources that increase the project schedule and drain the project budget. Some runaway projects result from an organization not making the appropriate decision to "pull the plug" on an unsuccessful project. The decision to terminate a project is not an easy one if egos and perhaps even careers or jobs are on the line. This phenomenon may also occur when the project has a high payoff to the organization and when admitting to failure is strongly against the corporate culture (Keil 1995). No matter what the cause, project resources are eventually drained to a point where a potentially successful project becomes unsuccessful (Nicholas 1990). Attention to defining and agreeing to the project's MOV, the project scope processes, and timely project reviews can reduce the risk of perpetual projects.
Thoughts
ID:1246620
Apr 25 2013, 11:17 am
|
|
A case in point is the project I'm currently on. I wouldn't say it has a life of it's own just yet, but it's a good 3 years overdue on it's first release, thanks in a good part to the customer basically going "Oh, and we want this new thing included too" every 2 months, without fail. Which when the features they want added take 6 months, is a recipe for disaster.
In part, the project managers on our end also have a duty to go "No, not until Release 2". Our problem I think is the sales team agree to the change, then project management get to hear about it. As we're a time and materials project, I guess in theory it makes no odds to us whether or not we release, so we just let them do it.