How to handle a large and ambiguous requirement with a fixed timeline/deadline (9 months to deliver)

Question

This was asked in an interview. I had one such experience in the past and at that time a single developer and PM initially conducted a pilot (manual + semi-automated) for a month/two to understand the requirements well. In other scenarios it might require the team to build an initial prototype/beta and then seek feedback from users before finalizing on the final requirements. Once you have the mvp requirements nailed out then it follows the regular process of finalizing the roadmap for the remaining 7 months or so with periodic checkpoints and finally a month for user acceptance.

But the interviewer did not look happy with that response. So, just checking with others if there is another method to handle such a requirement.

The only other thing I can think of is lean startup kind of methodology where I build iteration after iteration and move the product closer and closer to acceptance (as and when the requirements get clearer with every release). But that way I will never be sure if I can meet a fixed 9 month delivery schedule.

Answer 1

With a fixed deadline you have two elements of the development iron triangle left to play with: scope and resources.

A typical agile approach would be to (at least initially) fix the resources and start iterating. The idea would be to deliver as much value as possible against the list of requirements. The customer might not get everything they want, but they should at least get the most valuable functionality by the deadline.

If the customer required you to deliver all the functionality by the deadline then the only thing you have left to play with is resources.

It would make sense in this situation to start iterating immediately so that you:

• Collapse as many unknowns as quickly as possible
• Get a feel for the velocity that you can achieve
• Get feedback from the customer at the earliest opportunity

The hope is that by doing this you can get a better feel for if you have sufficient resources to complete all of the requirements by the deadline.

The usual caveats about adding resources late on in a project apply. You need to discover as quickly as possible if you need more resources, so that you have the chance to bring them onboard, get them up to speed and then evaluate their impact.

Answer 2

TL;DR

The question itself is unanswerable from a Q&A perspective because there's no canonical answer. We don't know what the interviewer wants to hear, and we can't guess at "correct" business decisions that really boil down to contractual issues between the company and their client.

That said, the question you posed is likely an X/Y problem. The underlying issue is buried in the question, where you say:

But the interviewer did not look happy with that response.

You and the interviewer were misaligned, and the solution to misalignment (in an interview or otherwise) is always communication.

Ask, Don't Tell

Some things have yes/no, black/white, clear-cut answers. Some don't. Interviews, much like project management in general, are really about managing expectations. In this case, the interviewer was probably looking for a specific type of answer or a specific approach to problem-solving. It sounds like you didn't hit the mark on their unspoken expectations.

So, what should you do when someone doesn't like the answer you provide? Start a conversation about it! Instead of leaving an unsatisfactory answer lying on the floor, you should pick it up, dust it off, and hold it up for collaborative inspection.

Interviewer: What would you do if the project parameters will lead to doom and gloom?

Job Seeker: I would embiggen the widgets, maximize the floobits, and widen the therbligs.

Interviewer: I have a sad.

Job Seeker: Well, there are certainly other ways to approach the problem. Do you want to hear some alternative ideas, or did you have a specific approach in mind that you'd like me to expand on?

This approach embodies two of the four agile values:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation

Agility is all about conversations and collaboration. Any interview for an agile role is likely exploring your capabilities in that regard, and you should be deploying those capabilities in the interview itself.

Answer 3

I'm struggling to see a better approach than a standard agile backlog and fixed date/variable scope approach however as Todd points out this is difficult without knowing what the interview wants to hear. That's where the discussion comes in.

Having said that, if I was asked that question I would discuss the how I would break down the requirements as far as possible and list them all in in order of priority, something cannot be worked on until it is properly understood (regardless of how important it is) and you can't start something and until all it's dependencies have been completed.

Once you get going I would explain how I could use the team's velocity to predict (avoiding detouring into planning poker and estimation of workloads to keep the answer on track) how much work which will be delivered by the fixed date and add confidence levels for over/under achievement. Periodically update this estimate as you get more data (and the client restructures the backlog) and make it very obvious which work I'd expect to be delivered and which won't make the cut.

I'd also stress the importance releasing little and often, not only for feedback but to make sure you're not doing a big bang release (I'm assuming you're talking about software here but it applies anyway). The risk of getting something wrong (like an environment not working or a customer not getting what they want) are vastly reduced by releasing as often as possible.

Answer 4

Ask more questions to the clients and prioritize which features must be done first. Agile methodology is the common practice

Answer 5

I think the other answers here are quite strong. I'm going to add one more almost as an edge case.

We know that the timeline is fixed. That means the only opportunity to manage is with scope or resources. If it must be done in 9 months, then we can either shrink the scope to that which can be done in 9 months with existing resources, or we can increase the resources until we have enough to do the task in 9 months.

(I'm going to ignore the opportunity to manage resources. That is an academic option; in reality we rarely have the ability to alter resources, and when we do, we run into the mythical man month - the effort of adding new resources may actually delay our work. This is a 9 month deadline and I don't think there is any way to bring new staff up to speed).

We know the scope is ambiguous. In my opinion, this is the risk/opportunity. If I were in this situation, I would:

• Work to reduce ambiguity by clarifying scope. The highest priority is to reduce the ambiguity in the scope. Meet with stakeholders to do two things.

  • First, identify the parts of the scope that are not ambiguous. We want to get the team working on the stuff that everyone agrees on. We don't want staff sitting idle while we argue about ambiguity.

  • Once the team is in motion, start working to clarify the scope. What is definitely in scope, what is out of scope, and what are the discussion elements? My temptation would be to use something like the MoSCOW model.

  As the scope clarification progresses, keep working with the team to estimate each requirement. Use the estimates as a feedback loop to the scope clarification process - very quickly you're going to have to start making the statement "That is a valid requirement, but adding it to scope runs the risk of slipping delivery beyond the 9 months timeframe." Estimates for each requirement are going to have to be in confidence intervals (To do requirement X, will probably require Y weeks. Best estimate is Y-Z, but worst case is Y+W. I'd estimate that there is an 80% chance that we can do Y within Y+V).

• In tandem with clarifying the scope determine the governance - who has the authority to add a requirement and increase the chance of missing the deadline? Who has the authority to accept that the risk of missing the deadline rises by 1%? Who needs to be consulted? Who needs to be informed? Under what conditions can the PM declare that the project has missed the deadline and that success is no longer possible? This includes stakeholder analysis and communications planning (which stakeholders need which information, how often, through which channel? What are the triggers for each risk?)

There are many other techniques that could be used to manage this project, but to my mind if the duration is fixed, then the PM has got to double down on managing the scope.