# Estimations in un-known position

### General recommendations

It's very clear that poor or unclear requirements may lead to project delay or failure. Poorly specified requirements can lead to: lost development time, missed project deadlines, poor quality of documentation the list of causes that can go on and on.

Recommendations on how to deal with unclear requirements:

* **Go for Agile -** Whether it's having unclear requirements or lack of customer involvement in requirements development, it looks like agile practice can go a long way in mitigating risks. The good thing is that we can start with what we have and go for an iterative development cycle by requesting feedback from customers at every stage of development. And at the completion of iteration, team members can show stakeholders the completed work and review the results.
* **Try phased -** Divide the project into different phases and work with the unknowns. I think when it's broken into smaller pieces they are much easier to tackle. Also, this will reduce risk and also ensure the involvement of the right people at the right time with the right tasks.
* **Add to risk -** When the requirements are not clear we need to record that the estimates are based on unconfirmed assumptions. The next step is to report the risks to the leadership so that the issue can get visibility and identify any impact on the timeline. Assign an owner and include a resolution target date. If the action owner confirms that assumptions are wrong, we can reestimate with a change management process.
* **Make assumptions -** Normally the PM can start the project with some carefully planned assumptions based on the best knowledge on the domain. Then the team can build the estimates based on these assumptions. The key point is to ensure that these assumptions are available and visible to the project stakeholders, by recording them in the project documentation.
* **Communicate with stakeholders -** As usual communication is the key in project management, so If the project manager does not communicate that the requirements are not clear to stakeholders, then there will be confusion and misunderstanding. Having clear requirements is always important to measure the project success, as it allows the team to compare planned and actual results
