I have a project that's close to failing as the main developer has now left the company. To help get a sense of where the project is at, I created a thorough review of the project's WBS and the tasks that were completed.

Unknown to me earlier, the owner of the company told the lead dev to get the project done by x date and the lead dev is now going to start working using the document I created.

My concerns:

  1. The lead dev does not wish to provide the number of hours required to finish the remainder of the tasks (so I don't know how meeting x date is possible or it feels like it's out of my control). Should the lead dev not provide the number of hours so that a schedule can be properly created?
  2. I want to sit down with the lead dev and the secondary dev to get a sense of how they plan to accomplish finishing the remainder of the tasks by x date. Ideally, I would like to allocate tasks by date, i.e. finish task 1.1 and 1.2 by x date, 1.3 by y date and so on. Is this in my place to determine this (I'm being told it's not)?

I'm being told that I should let the lead dev plan this out and I am only to be given a percentage of completion.

I'm fine with any approach, but given that I have a technical background, it feels odd not to have a deeper insight into this project after spending a gruelling 7 months learning everything about it.

  • I think a clearer understanding of the situation would be useful. You mention taking 7 months to come up to speed on the project. Were those months before the main developer left or after? Is the new lead dev someone that was already involved with the project or someone that was brought in after the person left?
    – Kyle
    Commented Jul 19, 2013 at 16:37
  • Fix scope and dates, nuke quality. Commented Jul 23, 2013 at 9:46

3 Answers 3



Your organization suffers from prima donna programmer syndrome and management seems to actively support this culture. The success or failure of the project rests with management, not with you, so voice your professional opinion politely and then let management assume their rightful responsibility.

Ideal Roles

The whole point of having a technical Project Manager is to have someone in the role who can evaluate the project schedule, resources, and control through a more technical lens than the typical PMO-type resource.

In practice, that means you should be having technical discussions of scope and objectives with the team. The goal of these discussions isn't to drive architecture or tactical coding decisions, but rather to be able to accurately assess the progress of the project through visibility into the deeper technical layers and to control technical-scope issues that arise.


You have no authority on this project. When you say:

I'm being told that I should let the lead dev plan this out and I am only to be given a percentage of completion.

one assumes that you aren't being told so just by the developers, but by upper management as well.

While an adversarial relationship with the development team is unfortunate, it is also unfortunately not uncommon, especially with traditional project management methodologies. However, having the management team tell you that you are responsible for opaque reporting (e.g. "50% of the project is 80% done") is undermining your ability to deliver clear metrics and a transparent assessment of the project's current progress.

That is ultimately management's responsibility, not yours. While you have a professional responsibility to address the status of the project and the effectiveness of the project controls (if any exist), you are neither authorized nor empowered to actively manage the project. Therefore, don't; politically, the attempt will not serve you well.

Career Advice

Whether this project succeeds or fails, it seems clear that the culture of the organization is actively hostile towards project managers or effective project management controls—and possibly both. Unless you like being on the hook for things over which you have no control, I strongly recommend looking for another job at another company.

Always do your best in any job for as long as you're there. However, don't take blame for things that are beyond your control, and don't let a toxic culture mark the end of your career. It's up to you to take an active role in managing your career, and from your description it sounds like making a graceful exit is the only thing left to do unless you enjoy tilting at windmills for its own sake.


Company culture always dominates PMI principles; if the owner of the company told the lead developer that he is responsible for finishing the project by X date, then the lead developer is responsible for finishing the project by X date.

What is your role as a project manager? PMI has a simplistic answer and a long winded answer, but practically in this situation your role is to:

  1. Monitor the project and estimate the probability that it will complete successfully on or before the deadline.
  2. Identify anything that reduces the probability of successful completion prior to deadline.
  3. Identify anything that would increase the probability of successful completion prior to deadline.
  4. Make sure that your management knows whether the project will complete on deadline.

Your lead dev is hinting that your attempt to obtain greater visibility falls into #2; things that interefere with successful completion. You need to find a way to ensure that the lead dev succeeds. I think in your shoes, my highest priority would be to work with the lead dev to identify obstacles that I could remove. If that means that I take responsibility for hourly caffeine deliveries, then I'll ask how they want their coffee. The number two priority is how to obtain low impact visibility into progress. Commit/checkin rates, QA surveys, unit tests passed, etc. might provide some insight. If they suddenly change, it might be time for another conversation with the lead dev, "Hey, I see that commit rate has dropped significantly; is there something I can do to increase your probability of success?"

My third priority is to capture lessons learned and improve process assets to reduce friction on this and subsequent projects.


The Technical Project Manager is meant to look at every detail of the project and guide the developers through the process of proper planning so as to ensure maximum resource efficiency and avoid any hiccups that may arise because of technical difficulties. The developer must provide a proper timeline estimate of the completion of the project and must have proper reasoning for it. This is where the Technical Project Manager comes in to question the developer.

  • It looks more like an advertisement, not a real answer. Commented Jul 28, 2015 at 8:45

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.