"What am I going to do now?" you find yourself asking out loud while staring at the ceiling in your office. "Should I de-escalate this project or press on?" It felt like you were in one of those management case studiesexcept that it was real and it was you!

You replayed the events leading up to this dilemma. It all started when you were appointed the lead of the project team in charge of creating the new human resources (HR) benefits package management system. You had made a very successful business case presentation and received public praise from the executive team. "Finally! Someone who does not speak techno-mumbo-jumbo but can present an IT project in business terms!" L.J. Lalli, the chief executive officer (CEO), had exclaimed. It had been your ability to interface with both the developers and the business stakeholders that had landed you the project manager position. You were the first project manager in your firm to come from a functional area (HR) instead of the IS function.

The project had proceeded very well, with great support from the user communityyour former colleagues, of course. This was due in large part to your knowledge of HR and your stakeholder-friendly approach. You had made a conscious choice to seek user feedback and to honor as many requests for enhancements as possible. "You have to freeze the requirements," Erik Khan, the lead system analyst, had objected. "Otherwise it's going to be anarchy." But you had dismissed his complaints as "development team grumblings." Those guys were never happy with a little uncertainty. Having been on "the other side" as a stakeholder in a number of system development projects, you knew full well that unhappy users were the fastest route to system failure.

Now you were beginning to second-guess your decision. The original schedule called for releasing the beta version of the application for user testing later this week. Instead, you had only 40% of the approved functionality coded. Moreover, your team was looking at a list of 22 enhancements, 2 of which would require a change in the database structure. Projected completion, without the proposed enhancements, entailed seven more months (a 45% increase on the original timeline).

It was now apparent that the original project had also been underfunded. The current estimate for finishing the project with the approved set of requirements called for a 62% budget increase (over the original). It was unclear how much more it would cost to exceed the requirements since the 22 proposed enhancements had yet to be evaluated by the system architect.

You were due to present a progress report to Ms.Lalli tomorrow afternoon, but you were still unsure about what course to take. The only certainty at this point was that you had to make your pitch for a project extension and ask for further funding at the meeting. Your plan was to report on the current state of affairs, paint a picture of the final product, and seek support. But what was the final product going to be?

1. What should your agenda for tomorrow's meeting be? Should you press on with your strategy, or is a change of course in order? 2. What would you do differently, if anything, given the chance to start this project all over again?