Project Leadership part 2: Probe for Details
If you have a good sense of what needs to be done in the beginning of the project, congratulations! I assume you’ve gathered the key information of the project that allows you to write up a plan for your team. But if you haven’t, what are some important details you need to know up front? Here in this post, I’m going to share some of the information that I deem as maker-or-breaker factors.
The Framework: 5W1H (with a twist)
Let’s start with a simple framework of project information gathering, then we can drill down into some fun stuff like where’s the pitfall, what techniques could be useful. The basic framework I’m introducing is the classic that’s taught in project management books: 5W1H, stands for What, Who, When, Why, Where, and How. You’ll need to know WHAT you’re try to build for WHO, and WHEN it needs to be done. More importantly, WHY are we building it? Then the implementation details like WHERE the end result is gonna be delivered (e.g. mobile app? other distribution channel?), and HOW it’s gonna be build (e.g. what kind of technology?)
You might have heard this 5W1H framework numerous time and are good at it. What I’m going to do is to bring in a bit of twist in it. The other side of the 5W1H, a team-focused, productivity-driven version of 5W1H analysis.
WHO are the contributors and decision maker
Assuming as a product manager or UX lead, you probably spend lots of time to expose to users in order to get the best insights out of them in order to make great product or service for them. However, just knowing what the users want doesn’t guarantee that you can create what they want. A lot of times you need to get the internal approval before you can launch a product to the market. Or if you’re in a startup environment, you’ll need to know where the funding comes from and how to get the next round of them. By knowing who the decision makers are and how they think, you will get a better chance to persuade them with your big plan.
As Aristotle’s rhetoric taught us, people have individual differences and they think differently. By knowing who you need to convince and what type of people they are, you can choose your way to approach them accordingly.
HOW do we work together
If you have ever worked in a big project team, you’d know how important the collaboration model is. I once worked in a project that consists of 4 product managers, 6 business analysts, 3 tech analysts, 4 UX, 5 SMEs, and 40 engineers. Without a clear collaboration model, what actually happen was lots of time people were just busy trying to find the right person to talk to in order to move things forward. For example, some engineers didn’t know that interaction designers only deliver wireframe but not visual design; or a UX didn’t know the difference between business analyst and tech analyst therefore kept asking the wrong questions.
In a situation like that, a RACI matrix could be very helpful to communicate “who’s doing what”. Below is an example chart of RACI matrix:
As you can see from the figure above, it clearly points out who’s responsible for what tasks, and where the accountability lands on, or who needs to be consulted or informed. A typical question that I’ve been asked a lot: what’s the difference between responsible and accountable? In Wikipedia’s definition: “Responsible” are those who do the work to achieve the task, and “Accountable” are the one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible. Simply put, responsible is the doer, and accountable is the delegate-er/approve-er.
WHY is it important for the business
Now that we know who you need to work with, it’s good stepping stone to get to know what everybody wants from it. It’s one of our most important responsibilities as a team member to capture the business value through our delivery. At the end of the day, unless you’re a business owner, we’re all hired to achieve a certain business goal. By working as a team with the business side and technology side, we will be able to achieve greater good with the combined knowledge and expertise. Simply sitting down with the business partners and discuss the goal they are trying to achieve helps inform better design decision and align the delivery to the business vision.
In terms of how to make it happen, I found Google’s OKR framework helps facilitate cross-disciplinary goal alignment. Other tools like Service Design Impact or UX Strategy Canvas also help outline the value proposition that’s key to success.
WHEN are we going to test and enhance
Now, moving on to the details. Since we know the high-level goals, the next question will be, how do we make it happen in a given timeline. How do we allocate the resources? Do we have a product roadmap? If yes, does it make sense to you? If you’re lucky, your product manager will consult you before s/he finalize the roadmap. If not, you might see a roadmap that didn’t account the level of effort from either the UX or tech side. As a UX practitioner, I try to work closely with the product team and tech team in order to construct a meaningful and feasible product roadmap. By meaningful, I meant seriously considering the release strategy that help us gain the best insight from our customers without risking too much of brand value. By feasible, I meant considering the actual effort in order to GOOTB (Get out of the building, test your product in the market).
With a better understanding of release strategy, the team can plan the effort in order to achieve separate goals in beta version, MVP, etc. For example, the UX team might sketch out the rough idea of the framework for the full version of the product, but only focus on the detail interaction for the beta of MVP release. The tech team will get to know what’s needed for the short term and work on the back end or middle ware strategically, so that it support the features in the earlier release but in the mean time scalable for the future releases.
WHAT do we want to learn (through user testing and product release)
From the UX side, there are many different type of research tools that can help us learn more about how users see/ use our product. In order to communicate the value of the data to the product team and tech team, I found Google’s HEART framework very handy.
The HEART framework help explains why the metrics are important in a non-UX-textbook way which can be easily understood by the business and tech team. Therefore, UX researchers or data scientist can focus on their great work without worrying that nobody understands the value and the impact of their work. This is not only important through per-launch user testing or beta test for qualitative feedback, but also for setting up the analytics metrics so that we can capture quantitative data.
WHERE do we pay detailed attention to
Often times we utilize different methodologies, design frameworks, in order to strategically deliver meaningful results. For example, if we’re designing a new product that requires lots of exploration, we might choose IDEO’s Design Thinking framework which emphasize upfront user/ product research, and prototyping/testing before product release. In my previous post, we discussed that it’s quite important to understand what type of project we’re dealing with, and carefully choose how to approach it effectively. One of the valuable things I learned throughout these years is that you will need a big UX toolbox in order to work with your stakeholders, your tech team, and your own UX team members. For example, some of the UX team members are eager to do more research work, and some would rather spend more time on iterating different ideas. Some of the stakeholders need to see pixel-perfect wireframe, while some others are happy with a napkin sketch for idea discussion as long as the prototype or build looks tight and neat.
Knowing how to meet stakeholder’s expectation is half way there of getting approval or funding. Some care about the big idea or break-through concept, some care about the aesthetic of delivery, some care about the way you communicate your progress/ process (e.g. present more than one ideas with pros/cons analysis), and some care about the implementation details (like typo, or the accuracy of sample data). As the driver of the project, the leadership really relies on how much you care about the team and stakeholders and how to motivate them to move toward the vision.
Summary
Obviously it takes time to figure out all the details you need to know as a project leader to drive the project with efficiency and efficacy. If you’re willing to spend some time to listen to your team, understand how they work, and provide the platform and environment to work happily, you’re not far from success. As former Apple CEO Steve Jobs famously said “it doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.” It’s our role as project leader to figure out where to look at and pay attention to details, in order to remove the blocker and move things forward.
What are some valuable lesson you learned through your project experience? I’d like to learn from you.
Image credit:
http://www.smetoolkit.org
https://www.pinterest.com/pin/158400111870081322/
https://interaction-design.org/
https://open.buffer.com/
http://mikewiggins.design/napkinsketch/
Cover photo by: rawpixel.com
