How To Demystify Unknowns
A Project Management approach to deal with lack of visibility (1/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.
One of the big challenges in a venture or complex corporate environment is to demystify a project where every is filled with complexity. During several decades of IT, the big question has been how to handle projects that lack visibility to achieve an end goal. Agile came to answer the plea but methodology alone does not address project unknowns. This article will be part of a series, to cover the steps that will help provide more clarity for the project execution.
To provide examples which can relate with a large number of readers, let’s imagine a fantastic project that would trigger both of our imaginations. Let’s have a look at the Starship project owned by SpaceX, and let’s imagine that Mr. Musk will hire us to put humanity on Mars by 2030.
Expert Judgement
Those who got their PMP recently will notice this is the input of several Project Management foundation blocks. The reality has shown that Expert Judgement, or Expert Opinion for all the Muggles out there without a PMP, is a fundamental block to provide more clarity into a set of problems. This is one of the easiest theories to show it’s practicality. In any project, if a PMs has questions about the feasibility of a feature or doubts about a set of actions, is common to gather opinions from experts.
If we want to send Humankind to Mars there would be the need to consult several kinds of experts: Avionics, Propulsion, Metalworkers, Physics, IT, etc. The different project teams need to design, understand limitations, brainstorm, need to highlight a set of tasks to have an overview of problems and end goals. It would be important to assess the current team’s knowledge and capabilities and how much is the gap for project execution.
For the cases were there is a lack of practical knowledge and depending on the resources available to the project team, the solution might be hiring professionals with the required skillsets or outsourcing some tasks to external providers.
Stakeholder Management
The importance of human factor on projects is huge. Different stakeholders have different risk tolerance, and the same situation would be seen with different urgency and overall understanding. It’s important to identify who are the key stakeholders, and their level of commitment to the project. Producing a RACI might be very useful to make sure everyone is aligned with their responsibilities. Each stakeholder might have a set of requirements that need to be agreed and contacts for arbitration might be used to address decision deadlocks.
The more challenging the problem is, the more stakeholders might be required to address it, therefore the higher the political complexity of the project will be. Having a strong governance with a central figure for decision-making is key. Otherwise, the project will be chopping days in the calendar, and with it, the budget.
For our Starship case study, each area has a set of responsibilities and levels of quality that need to be fulfilled. Arbitration could be performed by key department heads or delegated to Project Managers.
Once all the key stakeholders are identified and decision-making contacts are defined, will be important to understand the budget constraints. High-uncertainty projects might need deeper pockets than others. Is important to define thresholds where the sponsor is comfortable financing the project and how to budget consumption and a communication strategy should be in place.
Counter-measures should be decided in case the project fails certain thresholds, both on costs and timelines. Planning only for “Happy Paths” in high-uncertainty projects always produces big arguments and unpleased sponsors. Murphy’s Law is bound to happen somewhere.
Divide et impera
This section can be simplified as having a big problem and split into smaller, more manageable components. The best way to handle complex problems is to deconstruct and analyze with tools at our disposal and address some of that complexity. It’s easier to manage smaller problems, where we can test individual parts or make multiple iterations until having a working solution.
The Starship example is master on this. The system has been divided into propulsion (Raptor engines), metallurgy to find the type of metal that is light enough and able to hold immense pressure, the launching tower, etc. Looking at the engines alone, it has passed on multiple interactions since the very first star hopper prototype.
The complexity is best addressed by dividing the new system into multiple modules or areas. What specifications does the rocket need to have and is possible for the team to aim for it; What is the best metal to build the rocket; How can the heat shielding be installed, etc. If we see the initial project drafts from Starship, there wasn’t any water deluge system or any idea of using chopsticks to catch a rocket mid-flight. This only came into design when the teams realized the rocket were unable to use legs as Falcon 9 and any alternative would be costly in terms of weight.
The process of cutting big problems into small pieces, won’t guarantee a solution in the first iterations. However, the main goal is to have the complexity organized in manageable blocks until the end solution becomes apparent.
Proof Of Concept (POC)
The reality nowadays is the term “POC” continues to be fairly unknown to the general IT population. Other nomenclatures like MVP (Minimum Viable Product) have some understanding, but in some organizations, MVP is almost a finished product. Whatever the case, the important notion is to have a testable concept that allows the team to learn and test ideas.
If we witness the first prototype using a Raptor engine, it was basically a cylinder with legs. Space X tested the metal to test the pressures levels needed to hold the gas used as fuel, and flew with a early version of a raptor engine to see how it would perform.
There is great value in POCs and MVPs alike. It provides hands-on investigation which may provide insight to make definitive decisions about the solution. In previous projects, some of the POCs produced by my teams were critical to understand which development strategy worked best, saving countless days of misused effort. For Kanban or Scrum methodologies, this is where the Spike comes from. The PM sets some basic objectives for investigation, and Spike’s goal is to produce a piece of work that tests or prototypes an idea in a given timeframe.
If a Software team doesn’t know which connection to use for integrating data on another system, some POCs would send fake data of multiple sizes and methods into different connectors. It could provide insight of which would be the best technological approach as well as how to handle system failures. The main objective is to increase the team’s knowledge about the problem and the solutions proposed. Some of these prototypes might be reused in the final product, but the team should be allowed some budget for refactoring if needed.
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