You’ve estimated the effort.
You have person-days by phase.
The next question is: “So how many weeks will this project really take?”
This is where effort meets calendar.
And this is also where many projects slip.
Let’s look at a simple way to convert effort into a realistic, defendable schedule.
Step 1: Start with Effort by Phase
Assume you’ve already estimated person-days for:
- Requirements
- Design
- Development
- Testing
- UAT
- Hypercare
Example:
- Requirements – 20 PD
- Design – 15 PD
- Development – 80 PD
- Testing – 40 PD
- UAT – 10 PD
- Hypercare – 5 PD
Total = 170 PD
This is your effort picture, not yet your calendar picture.
Step 2: Decide Working Days per Week
Keep it simple:
- 5 working days per week
This gives:
Total weeks (if 1 person did everything) = Total PD / 5
170 / 5 = 34 weeks (obviously not realistic because you’ll have a team).
This is just a baseline.
Step 3: Bring in Team Capacity
Now decide your team composition, for example:
- 2 developers
- 1 tester
- 1 BA / PM support
You don’t need a perfect staffing plan, just a reasonable starting point.
Step 4: Apply Productivity / Boost Factors
Reality is not linear. Adding more people doesn’t always cut effort in half.
So you can define simple productivity boosts:
- For Design + Development with more developers
- For Testing with more testers
Example logic:
Adjusted Dev Days = DevDays / (1 + (Developers – 1) × DevBoost%)
If DevBoost is 30% and you have 3 developers:
- Factor = 1 + (3 – 1) × 0.3 = 1.6
- Dev phase duration reduces proportionally
Similarly, for testing, you can use a stronger boost (for example 80%) because testing work can be parallelized more.
This gives you a smarter schedule than simply dividing effort by number of people.
Step 5: Keep Phases Sequential (but Practical)
A simple model is:
- Requirements
- Design
- Development
- Testing
- UAT
- Hypercare
Some overlap may be possible in real life, but for a clean baseline schedule:
- Let each phase start when the previous one ends
- Later you can overlap based on confidence and risk appetite
This step gives you a clean Gantt-like picture in weeks.
Step 6: Visualize the Schedule in Weeks
Once you know the duration of each phase (in days), you can:
- Convert to weeks (divide by 5)
- Map phases to week numbers:
For example:
- Requirements → Weeks 1–3
- Design → Weeks 3–5
- Development → Weeks 5–10
- Testing → Weeks 10–13
- UAT → Weeks 13–14
- Hypercare → Week 15
Even a simple table with rows as phases and columns as weeks gives stakeholders more clarity than just “3 months”.
Step 7: Use a Schedule Generator Instead of Doing It Manually
A Schedule Generator can:
- Read phase-wise efforts (from your estimator)
- Take inputs:
- Developers
- Dev boost %
- Testers
- Tester boost %
- Calculate adjusted days
- Convert to weeks
- Plot phases into a grid
- Export to CSV or Excel
This reduces the heavy lifting and lets you focus on scenario discussion instead:
- “What if we add one more developer?”
- “What if we add another tester?”
- “What if we reduce UAT duration?”
Step 8: Communicate Schedule as a Range, Not a Single Date
After you generate your baseline schedule, add a realistic view:
- Best case (if things go smoothly)
- Likely case (with reasonable delays)
- Risky areas (integration, environment, third-party dependencies)
Instead of saying:
“We’ll go live on 15th November.”
You can say:
“The plan gives us a 14–16 week window.
With current assumptions, we’re targeting mid-November, with risks around X and Y.”
This feels honest, professional and grounded.