Let's discuss agile decision-making in detail.
How much information do you need before you make a decision?
Some people wait until they have all of the necessary information before making a move. With decisions that are widely reaching or high-profile and affect a lot of people or programs, gathering as much data as possible can make you feel confident you have considered all angles and are choosing the best one for all involved. But this isn’t always possible. Or it simply might not be the best choice. Being agile allows you to keep operations moving smoothly once you have enough information to begin, and leaves you prepared to make smaller tweaks when more information comes along.
So how much information is enough? And how do you know when you are ready to make a decision or begin a project?
Communicate the Uncertainty...and Play Well with Ambiguity
On my marketing and communications team, I often am the one setting the overarching vision or strategy, and then I select a due date and create a project plan that works backwards and captures all of the associated deliverables, or I empower my team members to choose a publication date and apply our project plan template to the package at hand.
But sometimes, when our content involves other teams or parties, a piece of information is missing, such as the due date. Sometimes we are told about a high-level shift in strategy or are presented with a general request (e.g., cover topic x, promote event y, achieve goal z). In these cases, I typically ask a few questions up front so I can figure out if I have enough information to move forward.
That’s when I, as a leader, have to decide what is “good enough.”
Following the due date example, I’ll ask up front if we know the due date, so I know how much time we can spend on the project. If a due date is not clear from the start, then that is when uncertainty creeps in.
I then will talk to my team about the project, and I will convey the uncertainty to them. That way, they will know that if a due date is assigned to us that is sooner than expected, at some point we’ll need to either simplify, cut some parts out, push back, or simply move faster so we can complete the short turnaround. Communicating the uncertainty up front prepares them for the unexpected and puts them in an adaptable mindset. They know that a change might come or they may have less time than they thought to complete their deliverables, and they’ll need to pivot or re-prioritize or adjust. If I assign the project but wait until the new deadline is available before telling my team when their work is due, they might feel flustered about having less time than they thought, conjuring negative thoughts (plus, this isn’t sustainable and is a surefire way to breed burnout). And if I don’t even assign the project to them until I know when it’s due, they’ll have even less time to complete their parts, which will be unfair to them, and both quality and engagement will suffer. But because I have been doing this for over 15 years, I tend to know how long a particular request might take to fulfill, so I can give a ballpark timeline to my team along with the general strategy for the project so that we can work together in navigating the uncertainty.
Start Now, Tweak Later…and Communicate Throughout
Take the information that you have now, and make a decision based on what’s available.
Then, when you have more information, make little tweaks based on the new data.
This is sort of a play on Maya Angelou’s quote: “Do the best you can until you know better. Then when you know better, do better.” While this quote could be applied to much deeper and more philosophical situations, it can also be applied to project management.
In other words, do what you can with what you have. Then, when you get more information, make small changes based on this new data.
This will keep you agile and productive, instead of waiting idly for someone to tell you what to do.
Because you have already started the project, the changes you need to make down the line will be minor tweaks rather than starting a new project from scratch or holding up impactful programming. That is the hope—if you did the appropriate data-gathering before starting.
See, this works best when you feel you have hit a threshold with the project request where you have just enough information to begin.
And in order to do that, ask yourself what you need to know in order to make a decision.
For example, if I have to assign a new content resource to my team based on a cross-departmental request, I need to know certain strategic elements, such as the audience, the strategy or goal, and the hook or lede.
Who is going to see this? (Is this for internal or external usage?)
What is the goal of this piece?
How will this be used?
What is the one main point we’re trying to get across?
Then, I need to know the details that back up those higher-level elements.
Do we know enough about the product to write effective copy?
Do we have a solid understanding of the topic being covered?
Do we have any data to back up this point?
Is there anything we want to avoid mentioning?
Next, consider what’s missing and how to fill those gaps.
Do we need to do additional research or data-gathering internally or externally? Do we know where to look or who to talk to?
How impactful is the missing information? Will new information change this project entirely or can we make and act on any assumptions that will only require small changes later on?
Don’t forget about the strategy behind the request as well. Some requests have to be fulfilled no matter what, but others might propel you to take a step back and consider whether the request should be discussed first or even disputed.
If we are promoting a product, is that product ready to be used? Or should we wait until the product is more fully built before promoting it?
Why are we trying to get this message across?
What is the best wording or messaging to convey this perspective?
What is the best format to get this message across, based on the audience?
Lastly (or sometimes firstly!), for project management purposes, it helps to know the due date (as mentioned above!) and who will be responsible.
When is this needed by?
Who will work on this?
Who needs to provide review or approval?
(If it’s an internal resource) Who will this need to be provided to, and who will handle that communication? Where will the resource be saved and who will save it there?
As the manager of the project, it is up to you to figure out which details are absolutely necessary for you to know in order to begin the project. Most times, you can probably start working on it if you know some information, like the topic, voice, and team members who will work on it.
Just be sure to communicate what you are still waiting for and what will happen once that information becomes available. Don’t take anyone by surprise; use effective communication to convey any potential tweaks you anticipate coming down the road, and equip your team with the knowledge and mindset to deal with those changes as effectively as possible.
Working with less than 100% of the information is very common. In fact, you’re probably doing it almost 100% of the time! If you waited until you had 100% of the information for everything you did, you’d probably never do anything. You’d be paralyzed with uncertainty. But that’s not effective, productive, or sustainable. Learning to measure what threshold of information you need to reach before you can start working on something is an art that will benefit you throughout your career.
And remember that moving and being productive and getting things done simply and quickly yet strategically and effectively both a) makes you indispensable and b) is much easier when you take an agile approach. Figure out the minimum amount of information you need that will still make something effective, then start acting on it. More questions will likely arise during the process, and that is fine if not integral. Ask those questions when they arise.
Don’t wait for the answers before acting; you’d be waiting around forever. Communicate now, communicate later, and act whenever you have just enough information to begin.
コメント