Time estimation of a product before developing the UI

Question

I work at a newly found software house as an operations manager. I am currently assigned with developing a project lifecycle framework from getting the client requirements to sign off. Constraint is that we are supposed to provide time estimates in the statement of work which is done in the pre-discovery phase.

These are the phases of the project in our company:

1. Pre-Discovery (getting requirements to providing the statement of work)
2. Discovery for UI/UX (getting user flows to developing models and user stories and user personas
3. UI/UX (develop figma or XD design)
4. Testing of UI/UX (perform various types of tests like A/B etc on the design)
5. Discovery for development (responsible for team allocation to completely planning sprints)
6. Development (use agile methodology and sprints to perform the development)
7. Staging (test the entire app) (also, the development is done using test driven development so this process is optional)
8. Sign off

My goal in this question is to provide a time schedule to my client with minimum probability of overrun and stress to my developers

For a project with UI/UX developed, that is not a problem but consider a project without UI/UX. I only have either the SRS document that only tells me the details of what the client wants. This does not seem to be enough to build a PERT diagram because I would not know what leads to the other. It is only after UI/UX I can decide the PERT diagram for my project. So my question is, how to develop a PERT model before the UI?

Also, for individual components I could not find a proper way to understand how to estimate optimistic, pessimistic, and realistic time estimates. For instance a "rich text editor with mathematical equations". Since none of my team mates ever developed such a component, how to estimate time for such a component?

Possible Solutions

for Q1) I can share the requirements with developer and UI/UX professional so they can build flowcharts and hence estimate the components they would use for each process to develop and set a rule that they should stick to those components during design phase. And simply calculate times for each without a PERT model. But then how do i estimate testing time and whatnot.

for Q2) I can build a planning phase where each developer can develop a plan on how would they develop the component.

Side note: I am not a project manager but I was given the task because its a pretty small organization and I opted for a management position after developing apps. Although i have a background in mathematics and economics so I am well versed with network flow diagrams etc.

Answer 1

You Can't Do What You Want Within Your Processs Constraints and Assumptions

My goal in this question is to provide a time schedule to my client with minimum probability of overrun and stress to my developers[.]

If this were a solvable problem reducible to a mathematical formula, it would have already been done. There is no silver bullet. However, there are lots of anti-patterns, so try to steer clear of those.

In particular, consider the following orthogonal problems:

1. I am currently assigned with developing a project lifecycle framework from getting the client requirements to sign off.

   Pragmatically, this means you're doing "big, up-front development" (BUFD) that almost demands a very prescriptive, waterfall approach with detailed specifications, fixed scope, a lack of ongoing customer engagement, and inevitable change orders. This will not really help you meet your stated goals.

2. Also, for individual components I could not find a proper way to understand how to estimate optimistic, pessimistic, and realistic time estimates. For instance a "rich text editor with mathematical equations". Since none of my team mates ever developed such a component, how to estimate time for such a component?

   This is an inherent problem with BUFD and top-down project estimation. Without ongoing customer collaboration, it's difficult to get all possible specifications nailed down accurately during project initiation when the cone of uncertainty is large.

   In addition, you (as the presumptive project manager) have no data on which to base estimates. Even if you did, the only people who can accurately (or even probabilistically) estimate the time and level of effort required to do the work based on their domain knowledge, level of experience, and tooling are the people who will actually be doing the work. In this case, that means developing a plan without input from the developers is simply asking for random guesses.

Mitigating Techniques for Your Framework

While there are certainly other frameworks that might work better for just-in-time planning, emergent design, and accurate estimation, your framework isn't one of them. If you can't change the project management framework or the customer-engagement framework, then you can at least ameliorate some of the risks by increasing collaboration, transparency, and architectural/engineering engagement up front.

I'd recommend some or all of the following activities during your initial project planning:

1. Work with the development team (or at least subject-matter experts) help you estimate the work. Don't do it yourself, and try to gather estimates from the actual implementers whenever possible.
2. Add lots of slack to your project plan. I'm not just talking about padding here; queuing theory requires slack in order to avoid logjams, so every activity should be represented as range that accounts for both the happy and sad paths, as well as some flex so that inevitable scheduling or other resource errors can be absorbed without having to re-baseline the whole plan.
3. Build story spikes (or whatever you want to call them in your framework) into your plan as work packages so that you have the time and opportunity to identify, explore, and evaluate various approaches within the project itself. This will not only provide some needed slack, but can also help you manage the cone of uncertainty by deferring decisions about known-unknowns until the last responsible moment within the project.
4. Assume there will be changes and add phases, gating criteria, and other inspect-and-adapt milestones into your project plan. There will be changes, no matter what you do, so you may as well plan for them up front as best you can.
5. Ensure the project defines a change control process so that when change is needed, you've already got a plan for how to communicate what's changed, how to address variances in schedule, scope, or budget, and how to work with the customer to adjust the constraints of the project from a contractual perspective while helping them reset their expectations. There will be changes, so not having a defined process for managing the change control process baked into the project's charter is a terrific way to ensure it is among the 68% of most projects that fail.

While not exhaustive, hopefully one or more of the points above will help. Feel free to pick and choose, or to find others that fit your particular situation better, but this short list should definitely give you a solid starting point.

Embrace Change

The key to success with any framework is really to admit that some amount of change during a project is unavoidable. Be honest with yourself, your team, your stakeholders, and the customer about that. BUFD isn't inherently evil; it is just impossible to get it exactly right from the beginning. As Carl von Clausewitz famously said (although I may be paraphrasing):

No initial strategy survives engagement with the enemy.

This is just as true in project management. No matter how perfect your schedules, budgets, PERT or Gantt charts, or other plans may look on paper at the beginning of a project, they will not survive unmodified through the entire project lifecycle. That truism is why systems thinking and empirical control frameworks have become so predominant. Try to keep that in mind as you build out your project plan.

Answer 2

In short

It appears that you work with clients in a traditional mode, starting with an estimate based on little more than an SRS, whereas you want your teams to perform agile. So you'll issue an up-front estimate that is based on a foggy tip of a big iceberg, and once you start the discovery, you'll quickly find out the real expectations that might not be the ones initially expected.

It's like you're on the titanic heading straight to the the iceberg. You need not only a solution to the estimate issue, but also consider to organise the customer relationship with the customer that enables both parties to benefit from discoveries that are made and share the risks.

Some more arguments

Your approach has some interesting ideas. Nevertheless, I would like to illustrate the key problem in view of your own quotes:

6. Development (use agile methodology and sprints to perform the development)

It is only after UI/UX I can decide the PERT diagram for my project. (...) how to develop a PERT model before the UI?

What's the issue?

A PERT model expects you to have all the required tasks and their dependencies identified up-front, with an initial estimate of the optimistic, the expected and the pessimistic workload. This is incompatible with an agile approach, and even in traditional approaches, not suitable before the discovery.

Moreover, even if someone would solve Q1, you need to understand that the underlying math of the PERT model requires the estimates of each task to be independent of each other task, which is rarely the case in software projects. This means that you may calculate some numbers which appears to be rationally supported by PERT, but with a far greater risks of overrun of workload that you would assume.

What's the alternative?

For your estimate, you can start to make an initial hypothetic backlog, with the big identified SRS function expressed in terms of epics and stories. Let your team estimate this backlog. Even if none has done a specific part, everybody will be able to relate it (in complexity and time to something already made). Add to this the estimate for the discovery activities, and you have a first guess.

But at the same time you need to be frank with your customer about the high level of uncertainty. You need to agree a revision process of the estimate after the discovery activities. Last but not least, if you really want to be agile and not just use the term for marketing purpose, you'll also need to discuss with your customer the principles of your agile flavour and how backload and iterations will be managed and the criteria for the sign-off.