The Methods For Unknown
A Project Management approach to deal with lack of visibility (2/2)
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
This article is the second part of a series on handling a project’s unknowns. The first article, which can be found below, is dedicated to governance topics and provides useful tips for handling the initial steps of a high-uncertainty project. Moving forward to this article, we will focus more on the fun part: execution and methodology. For this article, we will continue to use our favorite example related to the Starship project.
Choosing The Methodology
Scrum fans, start your engines! The same is true if you prefer Kanban, of course. The important message is to choose the best methodology for the project. However, some teams might not be that lucky since in the corporate world, the methodology is dictated by IT governance. In this case, some tailoring might be needed to accommodate the project’s specific needs where the company’s IT governance dictates the use of Scrum or other methodologies: How long should be the sprints? Who will be the Scrum Master and the Product Owners and what would be their responsibilities? (To remember that different persons should hold those roles).
Some companies still don’t have an Agile mindset after two decades in the 21st century. For more traditional, waterfall approaches, there is a method called Rolling Wave Planning which in practice is sprints with higher timeframes.
Let’s imagine we need to figure out how can we reenter Starship on Earth’s atmosphere without destroying it, and Kanban is the selected methodology. It would make sense to create a dedicated Swimlane for the set of topics in regards to holding hull structure. The cases where we have no clue what to do and we need time to analyze, we would create a spike.
If we would adopt Scrum, would be highly important to have the key decision-makers in the squad or to be part of the 100 ceremonies that Scrum requires. It’s easier in a startup environment and Space X, however for a big corporation to have the head of product and the head of compliance on a Sprint Review is a challenge on its own.
For Rolling Wave Planning, the first wave should have every task to put Starship in the sky, and the second wave would be for addressing the bits that got burned during re-entry. This sounds like a joke (because kind it is) but each wave needs to provide more information for the team to use on the following wave.
Feedback Loops
The most important for handling unknowns is to have a continuous learning mindset. Agile takes this for granted and it’s on Scrum’s and Kanban’s DNA. However, for Waterfall methods, this can only be achievable realistically with rolling wave planning. The working method should empower information gathering and stakeholder feedback, to provide more insight on how to tackle complex projects.
These feedback loops should be blame-free. Is not productive to have a Sprint Retrospective and point fingers at why a set of features needs to be refactored. The team should have the freedom to speak openly about the problems and how it can be improved. The moment the finger-pointing starts, the issues will be hidden from different stakeholders and the bubble will eventually burst on everyone’s plans.
Continuously Updating The Planning
Whatever method is being used by the team (Scrum, Kanban, Waterfall), the main sponsor would need visibility when the components would be delivered. A continuously updated plan is key to providing this visibility. Also, the most uncomfortable updates to have. There are very few sponsors who have an Agile mindset, and they need it when a set of objectives are met.
The project team might produce a high-level project plan to give a picture of timeframes and maneuverability for the project and decision-making. The more the team learns, the more unknowns are cut from the project plan increasing their certainty.
Let’s imagine Mr. Musk planning to go to Mars in 2030. Not sure he accounted for all the FAA and regulatory struggles. Space X is producing rocket prototypes faster than the FAA can approve based on heavy regulation. After a while, the plan given by Mr. Musk was nicknamed “Elon Time”. In short, this reflects the credibility of the communicated timeframes is low to the point where nobody believes them anymore.
For any project that is handling high levels of uncertainty is easy to fall trapped in “Elon Time”. For my projects, I try to be the most realistic as possible to avoid my plans being called “Artur Time”. It’s very hard to push for a realistic scenario if perceptions are completely unphased with reality. A tremendous effort of communication is required to push for a feasible reality and make decisions in a practical position. However, the Project Managers tend to easily fall into “Elon Time” hoping the stakeholders realize their errors in the future.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur
The link for the first article
https://open.substack.com/pub/arturhenriques/p/how-to-demystify-unknowns