Welcome to the Simplilearn Community

Want to join the rest of our members? Sign up right away!

Sign Up

How to determine project duration

_5306

Member
Hi guys, if I am managing a project which is a new technology or new Business vertical where I am sure my Expert Judgement will not rightly work. How to determine the project duration?
In other words, after I defined my Activities, Defined Activity Resources, Defined Activity Resource Durations and come up with aggrigated estimated time, I considered Resource Calendar, Business Down time etc, but this is still on paper. When I go for execution, I will need to have CRP, Build, Test, then UAT(s), and then Cutover. So, Build Duration is the aggregated estimated time, but CRP duration, Build Duration, Test Duration, UATs Duration are unknown to me.
I am not able to find a way and support it with enough justifications to commit with Project duration.
Can someone please guide?
 

Ambika_2

Well-Known Member
Simplilearn Support
Hi ,

We have received your query. Kindly allow us 2 to 3 days to help you with this query.

Regards,

Ambika
GTA
 

tim jerome

Well-Known Member
Trainer
Thanks for the question - this is the ultimate dilemma. Please understand - this is not just a project problem, but a general business problem. We want to constrain projects to provide what stakeholders want, but are attacked from all sides by uncertainty, ambiguity, change, and the unknown itself.

PMBOK best practice is to decompose to the most base units possible, and estimate at that level. Then add those together. In real life, you have to determine the subject experts who can best guide you in estimation, and then observe probability of error through your understanding of errors and what you don't know right now.

At another level of detail, the PMBOK states:
  • If you know all requirements fairly well, plan-driven (bottom-up) will provide you a high level of confidence.
  • If you don't know all requirements, sometimes you can use iterative and incremental -
    • Use historic top-level estimates (and experts' knowledge), and reserve time for risk and error, but also confirm that time is not a major constraint.
    • Set expectation with every iteration - 'we generally know what we're getting into, but we have to be prepared to be surprised...'
  • If you know that your perception will change, and the end result will change as well (and maybe even business objective) -
    • Apply some flavor of Agile - SAFe if you are a heavily disciplined environment, SCRUM/Sprint if you want to take small steps.

Business understands this, but doesn't have to like it (much like us). At any time through product development and launch, you are battling success in alignment to plan, as well as accommodating change. Agile can help in some ways, if you have strong developers. Otherwise, the PM will adopt (as above) something like SAFe - a scaled approach that allows you to integrate change into not just the development of the project but communication to all stakeholders.

An old mentor of mine applied an iterative / incremental approach he called "crawl", "walk", "run". In the early stages you had to address feasibility - can this even move forward (crawl)? You can assume that it is very difficult to put time constraints around this - much like putting time constraints around a baby's first attempts to self-propel. When the project walks, you are testing practicality - can you scale what you have? Without scaleability, a product's hope for a future is dim. However, having crawled, you have a pretty good idea of what you'll need to do to walk. When you run, you support the public (true) launch, and transition to the support teams. This is well-trodden ground for all functions of the business. Along this path, there is regular review, analysis, discussion and decision-making - the controls needed to not only have a healthy project (or group of projects), but a healthy business venture.

All of these occur not only in engineering and development, but with marketing and sales as well (and every other support function). What you should start seeing is how critical communications and decision-making are at all parts of the work: top-to-bottom, start-to-end. This is why these critical types of efforts are structured as portfolios - running projects, programs, sub-programs, sub-portfolios as an actual line of business - which is what they are.
 
Top