Currently my Team and I are working on big project. It's almost done, however now we are stuck at testing and debugging. But we received an offer for another project which is also huge, and we accepted it.

That project needs to be released in 2 months, but we estimated around 6 months of work on it. So we need to get more people working, so that we can fit in that time period.

My plan was to get a project manager to help us with it, and currently I'm searching for developers who could finish it.

This is the first time that I'm facing a project of this scale, and I'm worried a bit.

Do you have any advice from which I could benefit?

I'm worried about managing more people than I'm used to...

  • 5
    1st piece of advice: You cannot simply add developers to make a 6 month project happen in 2. If you triple the team size I would expect the project to take 12-18 months to complete. 2nd piece of advice: Stop taking on impossible projects.
    – RubberDuck
    Sep 26, 2017 at 21:09
  • Your resource-based premise appears flawed because "9 women can't make a baby in 1 month."
    – Todd A. Jacobs
    Oct 5, 2017 at 18:47
  • @RubberDuck - I wouldn't expect 3 Development teams to increase a project by 200% no matter how many times I read The Mythical Man month. That seems extreme and not engaged with reality. I do agree that adding additional resource will not bring the timeline in and will possibly extend it. Oct 6, 2017 at 7:52
  • @Venture2099 I may have been a little dramatic, but I really would expect tripling the team size to (at least) double a 6 month project. This isn't from The Mythical Man Month. It's from the experience of working on a project that was ramped up to be far too large too soon for the last year. We spend far more time in meetings and stepping on each other's toes than getting any actual development done.
    – RubberDuck
    Oct 6, 2017 at 9:06

4 Answers 4


Oooooh boy... Where to start....

  1. If you're almost finished but you're "stuck" on testing and debugging you are definitely doing something wrong in the first place. Waterfall much?
  2. If you, or your salespeople, have sold a 6 month project to be done in 2 months you're in the hole already.
  3. None of these problems are actually related to your project management per se, except if it was a PM that said you can complete 6 months of work in 2 months.

Alright, let's try to get some answers. First things first: Fix your development process. At the end of the project you shouldn't be "stuck" in QA. Search (and learn) these: TDD, BDD, DDD. Testing is not something you do after coding. It's an integral part of the process. Feature is not done until it's tested. Period.

As for the sales people (or the PM if they was responsible). Well, that's a different thing. You have to assure them somehow NOT TO DO STUPID SHIT. I have no silver bullets for that.

  • 1
    Thanks for the reply.I mean by stuck that we are currently at it and fixing some strange behaviour.We finished it 2 days ago, and we are planing the current project now.I hired lots of experienced guys, and one project manager with experience(i found him over linkdin).I think that its going well for now.You helped me out, i learned something new :D Thanks for mentioning the terms.
    – DaAmidza
    Oct 1, 2017 at 15:50
  • No worries! Glad that I could help!
    – vvmann
    Oct 9, 2017 at 11:52

That project needs to be released in 2 months, but we estimated around 6 months of work on it. So we need to get more people working, so that we can fit in that time period.

Adding more developers will not solve your problems. Study of The Mythical Man-Month by Fred Brooks is recommended.

Also Testing & Verification should happen alongside of the project, not at the end only. The managing of more people, and particular intelligent people, needs - as with many things in life - trust. This small word (trust) means much more and you should consider its meaning. Also you must invest into learning about management styles.

Your estimation of 6 months needs to be squashed into 2 months, that is my recommendation. The two methods defined by PMBOK are Crashing and Fast tracking. Crashing means adding resources. I don't recommend this. Fast tracking means parallelizing your work. You must consider doing this with same headcount.

Your current people need to focus on finishing, which I find the the most difficult gate of projects. Sit down, discuss and maybe use fish-bone analysis to identify the particular item(s) that would need additional months. Maybe one of your developers can continue on this particular issue, while the rest of you move on and you increase the number of staff at your next project accordingly.

Additionally, I recommend - if you have not done already - reporting that you and your team are going to run late with high risk. If you secured the new project B, also prepare of an ugly ending with project A. You did not specify anything about the stakeholders and customer of project A and B. Is customer A more important than B on long run? If somehow project A and B continue, you half your speed for both projects and quality, etc. and your resources become toast sooner or later.

Good luck.

  • 3
    This should be the accepted answer. It actually answers the original question and is not a thinly veiled rant against the OP. Oct 6, 2017 at 7:55

I am reading three separate and distinct issues: 1) current team is "stuck" in testing and debugging; 2) new project with an initial target of six months and now a commitment to a target of two months; 3) fear of a stretch role.

1) What does stuck mean? If during your testing you're finding an abnormal amount of defects and defects skewed to a high severity, then I would argue you are not stuck in testing but rather not finished with development. You should kick back the product and finish development properly.

2) To analyze whether the six to two is an issue, you need to take a look at your assumptions and basis of estimate and the range of your estimate. If you assumed your current team who was "stuck" in the previous project, then perhaps you padded the six months in order to finish. Regarding the range, where did the six months fall? If you estimated one month to six months to finish, most likely three, then a two-month duration is aggressive but not unrealistic. If six months was already aggressive in your range, say 5 best, 9 worst, 7 most likely, then do not accept the two-month commitment. So there are a lot of unknowns about this project for anyone here to answer but here are a few questions to answer to get you started on that analysis. Read below on my opinion about task resource elasticity. Crashing your schedule by loading it up with workers is CERTAINLY an available option but you MUST evaluate resource elasticity in the environment in which you are working.

3) Get over it. Stretch. Lean in. Jump in when you are not comfortable. If you wait until you are comfortable, your peers will pass you by in growth and rank. You will make mistakes, which is fantastic because you can learn from them. Seek out a mentor.

Original but unacceptable answer:

Not a direct answer to this problem but a word of caution when considering the notion of the mythical man month. This is not a valid construct across all types of tasks. Don't just assume that adding employees would cause all tasks to increase in duration all the time. Different tasks have different degrees of resource elasticity and will respond differently, both up and down, when adding or removing workers against that task. Adding workers against a task can most certainly have a favorable effect on crashing your schedule in many circumstances so you need to evaluate the tasks at hand on a case by case basis.


What you should really do is to call product owner immediately and discuss details of the new project to reduce as much work as you can. You cannot complete project in 2 months if that requires 6. Have a long planning session and check every user story to get understanding of what is really needed for MVP vs what can be left for version 1.1 or 2.0. You should be open and fully transparent in your plan with product owner. Building trust at this early stage is much more important than trying to build something within impossible time frame.

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.