Mail Call! On your advice on the runaway project. The key here seems to be the changing requirements. You may be right on the rest of the steps, but the first steps would be to find the current requirements. Maybe not freeze the project, but certainly the requirements for a month. During that month look at the current requirements. Do they say anything? Do they actually define the project? Then look at the the p Mail Call!On your advice on the runaway project. The key here seems to be the changing requirements. You may be right on the rest of the steps, but the first steps would be to find the current requirements. Maybe not freeze the project, but certainly the requirements for a month. During that month look at the current requirements. Do they say anything? Do they actually define the project? Then look at the the past requirements and see what changed, and more importantly, why.One of the possible solutions is to make this a multi-version project. Put a version number on this project’s deliverables. Freeze the requirements with very few changes … for this project. Then schedule a meeting with all stakeholders to decide what features can be deferred to the next release. One of the reasons that people keep insisting on changes is that they consider that they have to get it right the first time. They do.But that isn’t the same as having to get it perfect. It needs to work. That is getting it right. But so long as you have multiple releases scheduled, the first one doesn’t have to cover all the possible needs – it doesn’t have to be perfect.and I have to disagree with some of the advice given. I am working one of these problem projects right now and let me tell you it’s not pretty. It looks to be getting cleaned up but no matter what you do your star will be tarnished. I went from being a superstar to lucky to survive. I would caution anyone not to enter into this lightly.Now on to my comments.Executive Sponsor – Good idea but good executives don’t get where they are by tying their fortunes to projects with a track record of failure. Even if they did they likely would do so relunctantly. Also, if this project is in the “disaster” category committing more money and staff to it is likely not a good idea. It may just perpetuate a lot of the problems that were there in the first place. From a business point of view this is a money loser and the executives will be looking to complete this at minimal cost. Governance Structure – Important but a low point on the list.Clear Charter – Okay I will give you credit on this one. This is VERY necessary and in my opinion they key point of fixing anything. If I were going into the project the first thing I would do is find out where the project is at (1 week not 1 month) and then sit down with the customer and project staff and find out what the high level goals are here. Make a clear statement that compromises will need to be made to finish this up. Find out all the complex bottlenecks that are killing this project and eliminate them or if not possible greatly simplify. It will be painful but in the interest of getting this project done it will have to happen.Project Organization – A good point and needs to be done. Project/Business relationship – If this project wasn’t allowed access to the User Community then that is probably one of the big reasons the project is a disaster.In summary you are absolutely correct that there will be no perfect situation going forward. My mandate on these projects is eliminate complexity, compromise, and move forward taking no prisoners.Bob’s Last Word: Multiple releases? Absolutely. Every software delivery effort should be based on this concept, and I’d advise scheduling a minimum of three releases when first chartering the effort, starting the planning for each release during the testing phase of the previous one, or even a bit earlier.That doesn’t mean I agree that moving to this approach addresses the root cause of project hell, though. If you don’t fix the other problems, all you’ll end up with is three projects in hell instead of just the one.As for the second set of comments … I don’t see that much disagreement. I agree with the assessment of how executives get to their exalted status, and that’s fine. If none of them are willing to step up to the plate, it gives the project manager the perfect opportunity to kill the project, which solves the problem for everyone. After all, if nobody wants the sucker badly enough to sponsor it, what’s the point of spending another dime on the effort? I don’t know that we disagree about the importance of governance, either, except perhaps for the label, which can be off-putting. After all, the next point talks about sitting down with “the customer” to make some hard decisions. What is governance, other than agreeing to who has the authority to make different kind of project decisions?All disagreements should be this agreeable.– Bob ——– Technology Industry