Inputs/Outputs: design planning in high uncertainty projects
Planning a project is not easy, especially if you face a fuzzy scope, unclear needs or business decisions, and a shortage of people to build it (not to mention a lack of the right talent to do the work); those are characteristics of a high uncertainty project. In addition, it can be tough to start crafting a roadmap or goal if you don’t have enough information to work on.
Not having the entire picture is the day-by-day routine in entrepreneurs’ companies; for them, moving fast to fail in the early stages may be crucial in the searching for numbers. This production rhythm bases its core on launching and testing to iterate and get better results soon(we are already familiar with this). Consequently, in this fast development mindset, sometimes there is no space or resources to gather all the required information to decide any further planning steps, so you need to make a move even though this means working across too many doubts.
In many companies, I’ve seen two significant characteristics(among others)of high uncertainty projects: 1. As a leader, you can decide where and how to start your planning based on your preconceived experiences (the idea is to envision this situation as an opportunity of having project ownership), and 2. You only will know one thing with total clarity: the results should come on the expected date, as a consequence, “whatever it takes” starts sounding like the most common approach among stakeholders; remember, we’re talking about money!.
How to achieve the goal? How do we encourage agreements and decisions? And even more importantly, how do you make the right decisions as a design manager? Here are some ideas for surfing among these projects full of an information mist.
The project context
Starting by knowing almost nothing, sometimes a very vague business idea, we need to start “designing” a plan to understand the environment we are moving to (you can do this exercise with stakeholders). We need to do this fast because we don’t have enough time to overthink. How to do it? The answer should be to combine the level of uncertainty over time. That’s the key! We know we need to deliver, but when? is it in the short term, the long term? How much do I know about what needs to develop?
I re-interpreted the well-known Eisenhower matrix in the graphic above to make it functional for design projects. Then, I propose a set of actions according to the level of information (uncertainty) over the date the product needs to be live(time).
Outputs of this ax:
- Responsive plan: Propose an initial path to follow, it is highly probable that it will change in time, but it can provide a notion of dimension for other team members.
- Negotiations: It is time to make tradeoffs; what can we handle(capacity), and what other priorities need to get out of scope? (If you have a small team, this is important).
- Only core experience: let’s focus on the essential function. Another thing beyond this is secondary, it can be part of the backlog for now.
- Fast adaptability: Don’t be afraid of wearing all types of hats; we need to seek solutions, and by that, I mean that we can be product owners, the sales department, researchers, or project managers (very common in small businesses).
Take what you can see.
The image above is a fragment of Charlie Mackesy’s book: The boy, the mole, the fox, and the horse, and there is nothing more accurate for high uncertainty projects than this. I’ve seen many leaders get paralyzed when they don’t know the endgame of the projects and miss the “right now” of things. Taking day-by-day solutions in these projects will generate a sense of resolution or progression that avoids the stress due to not knowing the long-term plan. In this scenario(high uncertainty / short term), we need to make things happen (fast adaptability), so no worries about the end of the road; that will come eventually. Instead, be worried about developing the proper communication channels to spark relevant conversations that reveal things’ shape.
“The more uncertain and dynamic the situation, the more proximate strategic objective must be.” — Richard Rumelt.
Anticipation
Although the term sounds complicated, you can turn previous knowledge and habits into advantages, as explained in the business book: Good strategy/Bad strategy. Knowing how things will behave provides you an edge against competitors. If you have faced projects of this nature, you probably know the inertias and constraints of the challenge, so use that knowledge to shape steps or workflows to help you see what others can’t by taking a solid position and creating options. An essential outcome of the stage is the ownership you can get once you start proposing a way through. The role of a manager is not only to take care of people but also to guide others toward a common goal.
Break all theory’s rules
Besides not knowing the endgame of projects, it is prevalent to suffer due to not finding the proper design artifact. Design frameworks provide a guide but do not always work for every need.
Beyond fancy concepts, frameworks, and names, the UX relies on an essential human input: experience and Logic usage.
In projects like this, we need to be enablers of solutions, so feel free to improvise on design approaches and artifacts. One big stopper on this challenge is to block a workflow; don’t be that person! Instead, encourage your team members to be creative and find new ways to reframe the problem; I’m sure that unique ideas will come up and work in other projects.
Short story: In my previous work, the design team didn’t know how to evidence the repercussion a new use case would generate in a system; A service blueprint was too extensive, and a user story mapping didn’t reflect the problem, as we wanted. We invented “impact mapping” to enlighten the problem in specific service areas. Technically, this new format didn’t exist, but at that time, it worked so well that it allowed us to evidence the real impact of this use case, and most importantly, stakeholders saw the real deal. Today, impact mapping is the first approach many design teams still use to evidence a UX problem.
The same problem
So far, we said we need to move faster toward the same objective and eliminate what is irrelevant, but we also need to confirm that we all have the same understanding of the problem/need; not having this will be catastrophic for the project.
In a short time challenge, there is no place for confusion among the team. Kick-off meetings solve these issues, but sometimes it is necessary to write things down and debrief if something isn’t clear. If we Break the theory’s rules, we can probably design new communication channels; in those “new artifacts,” we can enunciate or reframe the problem/need to clarify it to all the team. (Imagine disruptive ideas like using a wall, a poster, or another visual clue that does the job).
Project agreements
Even though we understand the same problem or need, we have to make people agree on some project expectations (mainly if we must report to investors). A perfect example of these expectations can be the acceptance criteria of functional deliverables in a given time.
Since we’re in a high uncertainty / short-term scenario, not having total clarity of what will be delivered can be extremely dangerous for business. A clear symptom of this issue is evident when no one in the room can state a solid release definition; then, once the product is live, it wouldn’t fulfill either business or user needs, and that’s a potential money loss and waste of time. How to mitigate this? Whether you have previous experience with this or not, be sure to evidence in a meeting or document all the constraints and viable solutions that make up the “final” shape of the product. Ideally, this is a product manager job, but it is not a rule; if you point out the issue, you can help to solve it.
Design status?
As another project, updates in a high uncertainty process are necessary. We need to evidence a progression and rise alerts that may compromise the primary goal. As the definitions are not clear enough, we need to adapt our answers to that dynamic
In projects, the bigger the uncertainty, the lower the precision; They are opposite forces.
What to say anyways? It is easy; focus on what you can support and sustain. Anything beyond this may be unnecessary at this point or worthless. We need to be efficient and not waste precious time debating on topics that don’t matter right now.
A piece of advice: write down all questions or ideas that come up; eventually, they will be relevant for future discussions.
Pivoting decisions, pivoting plans
Although undesirable in these scenarios, we need to embrace change and quickly adapt to the new rules. Depending on the project stage, we can decide whether to change the design strategy or turn existing ideas into new functionalities. As a leader, not panicking is key! Instead, evidencing potential impacts on the current system will provide the team with a notion of effort or complexity; therefore, it is essential to gather all stakeholders to discuss the new design decisions on the roadmap and get agreements.
Some action points in this situation:
- Understand the change (why)
- Measure the impact (I need to start from scratch? can I still use the same approach?)
- Plan the next step
- Rise alerts to stakeholders
- Negotiate the fundamentals
- Execute
Effective execution
Once we have the proximate objective (a feasible action in time and resources), we can move through uncertainty, so it’s time to build the product hypothesis. As a manager, it is essential to make the right moves within the team. Whether we face a pivoting business decision, the first agile action will be to revisit previous design solutions or experiences to recycle if relevant. Second, identify the designer’s profile strengths; depending on the need, we should assign the task to the team’s most skilled designer(s) and monitor progression.
Keep in mind some interaction tradeoffs; forget about pixel-perfect and other design subtleties, all of which will belong to a design debt artifact.
Some action points in this stage:
- Be sure that communication with developers is crystal clear; now it’s time to work as a unit (no time for misunderstandings).
- Revisit once in a while all the project agreements to be aligned with expectations.
- Do not forget about thinking in metrics; eventually, those are reliable for measuring the product hypothesis.
- It’s all about money, but also users! Be sure of a proper balance and not sacrifice too much due to business profitability.
- Deliver and measure
Final Thoughts
In all companies at any level, there always will be goals ambiguity, fuzzy decisions, and the fundamental need to be innovators in the market. That’s not new in the business culture; from a UX perspective, we can be facilitators and provide so much value on how to tackle these “aggressive” scenarios. Knowing how to move in these situations and not falling into management chaos is vital to gaining experience and learning.
There always be external factors that we can not control, but what we definitely can do is assume a constructive and positive work posture to face those challenges no matter the window of time or the level of uncertainty we deal with.
#ShortStoriesOfMyLifeAsDesigner
