I work for a pretty small company employing less than 150 people, for the last 35 years this company has never had any sort of project managers and every project that they have had has always come over budget and over the deadline. Two years ago, the company hired a new director who quickly started putting in place project managers. I was hired about this same time frame as a programmer on one of these new projects.

A few weeks ago, the director and my department head decided to put me in charge of the project that I have been part of for the last 18 months. They decided to go down this route because the project needs to be completed on time; which is 4.5 months away. The previous project manager was overwhelmed and they did not think he could get the job done.

The problem I am coming up with is that I have asked for the deliverables of the project and the previous project manager does not have them in writing from the sponsor or know of them. The culture of previous projects in the company is to wing it and hope that everything falls into place in the end. Since he did not know the deliverables (or would not tell me), I went to his boss to find the answers. His boss had a meeting with him and ordered him to get them from the sponsor.

Over the last couple of days I have started to receive them; it has been a slow process. After I had received some of them, I have found out that the sponsor wants more than what we have been programming for. How do I handle a situation like this?

7 Answers 7


When taking over a troubled project, one of the very first things you need to do is to slow or stop the train. If you let it continue to move, you will most likely continue on the same path and unable to introduce any meaningful intervention.

You need to get the sponsor at the table to redefine the project as if it is a new project. This means the sponsor owes you a new project charter. From here, develop the scope, which sounds like has never been done; the plan; the schedule; the required resources; and literally start over. This could mean the 4.5 months remaining could very well be a fantasy, and it is YOUR job as PM to relay this specific news. To do this, you need to get behind the fact that what has been done is a sunk cost and you NEVER chase sunk costs.

So, essentially, from your perspective, treat this is a new project that just so happens to have some artifacts of which you can take advantage. And the project sponsor(s) need to give you this latitude or else don't accept the job (if you can).

  • 10
    The "start as a new project" is a good concept to build your work around but I recommend that you don't use those specific words with the project sponsor. It often causes negative emotional reaction from the business people involved. They start to wonder why you've been wasting time and generally get upset. In my experience "clarify", "re-define", or "break down the work remaining" seem to have less emotional reaction
    – SBWorks
    Commented Jan 12, 2012 at 0:47
  • 1
    That is why I brought up 'sunk cost.' The sponsor should be mature enough to hear that the first attempt failed. By watching your words, you are enabling either miscommunication or the possibility of some of those root causes to continue. When you have a project that has derailed like the OP describes, it is time to call a kettle black and let everyone get angry, cry, or lick their wounds. Commented Jan 12, 2012 at 12:25

After I have received some of them, I have found out that the sponsor wants more than what we have been programming for. How do I handle a situation like this?

Part of what you need to do is triage the project: what can be finished, what can be finished only by scaling back and what cannot be finished in the time allowed (and needs to be dropped in "this release"). One book that gives examples of dealing with this sort of situation is called Catastrophe Disentanglement.

The culture of previous projects in the company is to wing it and hope that everything falls into place in the end.

I've worked for people like this. I have not found any simple strategy that is effective at planning that can survive them (indeed, I've had bosses who believe that planning is "evil" and will intentionally undermine any effort to react with anything other than last minute crises), and it takes more skill than I have to work around active intereference. The book Death March describes some of the rationale behind "wing and a prayer" project management, but more importantly deals with how you should cope with it (because sometimes the only rational response is to quit).

Death March is a quick read (like an evening), and your local library may have a copy. Catastrophe Disentanglement is a harder and longer read, it will require some effort to think about the techniques it explains and to sit down and trim your deliverables.


There's no way the project will be done on time nor to the sponsor's expectations.

Make that clear to the sponsor and start from scratch.

Instead of focusing on completing this project, focus on creating a new project. Prioritize what the sponsor wants and start delivering.


Since this is a software-related project there are several books available like the the ones referenced by @Tangurena and I recommend Business @ the Speed of Stupid by Dan Burke and Alan Morrison, too. Before making any major changes or having a heart-to-heart with management, I would do the following prep work:

  • Update Current Status: Talk to the team and review where they are, what they are working on, and what they are all planning to do over the next few weeks. You really need this information on hand for any real future planning.
  • Gap Analysis: Compare the information you received from the project sponsors and summarize all the things your are doing and all the things you are now aware of.
  • Phasing or Chunking: Depending on the type of software system you are developing, there might be very clear functionality breaks were you can partial deploy a system (back end vs. front end, back-office vs. client facing, etc.) and you might be able to take advantage of that. Delivering partial functionality that works is better than delivering nothing and you need to have those points identified.

Hopefully, this research has given you a couple of ideas about how to proceed. Now, you need to find out what your management and the project sponsors think in the best thing to do.

  • NOTE: Stopping the project should always be on the table. It might be the right decision.

This is not the time to have a meeting and say "You didn't tell us you wanted Feature X so we won't do it" and you'll kill any chance of success if you try to assign blame. I have had success with a "We've apparently had uneven communications in the past about what you wanted and we may have moved forward with misunderstandings but we want to clarify things now" attitude. Blame games, couldda-shouldda-wouldda, and if-only-we-knew conversations rarely fix projects.

Start the discussion with a status summary and then move to the gap analysis. That way everyone know where the team is, where the team is currently going, and what features will exist at the end. Then the actual discussions of scope/schedule/resources/goals can start from a common understanding. If you've found a good functionality break point, you can use that as phase-break to get the project back on track.

For example, you found that the back-end work was much cleaner and has fewer problems or missing features. You could try: "Since the client-facing section might change, why don't we concentrate on finishing the back-end and administration section? We can then re-evaluate the client-facing portion, clarify the requirements, and then start that portion of the project with a better plan?" You can then break the scope statement, schedule, and WBS into phases and restart the planning process for this section phase while the project team continues work on the other phase.

  • As a side note, you are probably already at your maximum "burn rate" in terms of people assigned to the project. Make sure to keep them working on something beneficial while doing all of this assessment and planning.

Finally, been there, done that, at least a dozen times over - it's not all bad news. All I can say is that things probably will turn out better than you hope.


I would stop the project until,

1- Letting know the situation to related people/managers inhouse since they should be aware of the situation clearly (if they are not yet)
2- Clarifying what the sponsor required
3- Clarifying what has been done so far.

As you involved in the project for the last 18 months, it may be easier for you to sort out what’s asked/ what’s done . If some additional works need to be done to the existing work(what has been done so far), then you don’t need to start all over the project again (hopefully).

After sorting everything out and deciding how much time it will take to complete the project, a meeting could be arranged with the sponsor and could be asked for extra time to complete the project with explaing the reasons (preferably one of the related top managers to attend the meeting as well).


Every project has the well known triple constraint:




If you only constrain two of the three factors, you can generally meet the third target. So given unlimited time and money you can produce about anything. Similarly given little time and money, you can generally produce something.

The problem comes when when you have a realistic plan and someone asks you to dynamically change one of the three in the wrong direction. For example you have a plan to build a new website that will take 1 month and require 1 programmer for that month.

Now someone asks: Could I have the same website in a week? (Perhaps if you give me more money to hire 4 programmers and pay them overtime)

In your case it looks like they have fixed the budget and time and want to change the deliverable, otherwise known as feature creep. You need to get agreement with your manager that when the deliverable is changed, expanded etc then the deliverable date and budget need to change as well. Changing the deliverable without allowing for more time is neither realistic nor fair and does not benefit the company in any way.


With what I understand from your situation, its seems more than only a "one project problem", but a complete organizational culture that you have to try to change. Congratulations! If you were chosen to do it, it is because the higher management finaly realized that you have everything needed to be a great project manager. As my collegues said (answers up); you should gather all the information concerning that project; but my point is that you should seize this occasion to make it a waking call to the higher management. They could increase their profits with a tighter management of all aspects of their projects (unless they do not care about that?). You should propose yourself to make a demonstration of your abilities and of your new way of managing a project. I would ask the higher managment to give you more time than the 4 1/2 months that you have. You could do the same with your customers (I do not know your situation exacltly). I would join 3-5 new people in your team (that have the same spirit as you) and motivate them to prove than, as a team, you can do better. And you will have a great time inovating to the benefit of all. Good luck.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.