How to plan with uncertainties?

At the early of the last two decades, the software development projects were more straightforward, with teams specialized in many things, and playing different roles. I remember that I used to develop the front-end, the back-end, and doing the testing. Sometimes, I had even to write the requirements and be engaged in business meetings to conduct the acceptance test. Also, after the launch of the project, I used to handle the support and reaching out to the users to resolve any issues they are facing.

The nature of the projects changed by time, along with the complexity and the team required to achieve project goals. Also, on the people level, the talents become more specialized, so there’s a talent for every activity. At the same time, the competition between the companies becomes high, so it’s not an easy job to find the right talent.

That’s why Agile find the way in the software development industry. The size of uncertainty is enormous in the initial phase of a project or designing phase for a product. It’s essential to think big and clearly define the objectives, but at the same time, start small and progressively elaborate the product and project activities. The regular waterfall methodology is not wrong or an old fashion that we have to throw it away; the problem is in the planning based on assumptions with uncertainty, not the approach.

ً Regardless of the delivery approach you are following, here are some tips based on my experience:

  • Log any uncertainty in the project risk register.
  • Review all the project documentation from the bidding phase, along with any customer-related documents (i.e., RFP)
  • Try to find a contact from the customer side to understand more about the expectations and the problems that the project shall address.
  • Look for someone in your connections, has a similar project experience (And maybe any other project with the same customer), and understand the challenges.
  • Avoid planning based on assumptions.
  • Validate any assumptions at the early stage of the project.
  • Plan spikes or short iteration to develop POCs that validate any technical or business uncertainties.
  • Focus on visualization over documentation. People can understand more through prototypes and wireframes.
  • Engage all the stakeholders in the project risks and uncertainties.
  • Avoid planning based on assumptions.
  • Any assumption not validated, has to be logged as risk and keep monitoring.
  • If it’s not possible to follow an Agile approach, work iteratively, and include a demo after each iteration.
  • Avoid planning based on assumptions.
  • If you are building a product, focus on the MVP, and launch your product as soon as you complete the MVP features. And collect the feedback to plan forward.
  • Check the company assets for similar projects to extract the lessons learned.
  • Avoid planning based on assumptions.

Any project comes with enormous uncertainty, disconnected and vague requirements. And the execution phase of the project is where the realization of the project come to light, and of course, when you realize something, you start to validate assumptions, the market needs, and your delivery capacity. The projects that can continue and succeed are the ones that follow a flexible approach in delivery and address the uncertainties at the initial phase

Post a comment