How can I complete 6 months of work in less than 2 months?

Question

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...

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.