If you can learn to communicate your value effectively to project stakeholders, you'll produce more successful projects and advance your career. Your credibility is crucial, and the best way to gain credibility is to show that your projects are well grounded, well executed, and contribute materially to your company's success.
This article outlines a set of tools that will put you in a leadership position, make sure your projects meet business goals, increase the support for your work, and, in the end, improve your credibility.
Define Success
First, you need to know what a successful project looks like. Success means that you and your team create a great solution to an important problem, that the solution is implemented relatively quickly with an appropriate amount of time and money invested, and that everyone has some fun along the way. It's a low-stress, high-results vision of success where creative, technical, and business people are mutually respectful and work together to accomplish something neat.
Somehow, though, stuff always gets in the way—schedules crunch, people get laid off—and more often than not, the important people don't really notice that something good happened. Or, what's worse, they do notice but don't see the value in it. Let's say you're an art director presenting the work at a company meeting. You point out the excellent interaction design, the layout and typography, the astute way that brand attributes are played out in the design. At best, the CEO smiles politely and gives some platitudes about what a great accomplishment it is. At worst, he or she asks how much additional click-through you expect as a result. You're an art director...you stammer for a moment and are actually grateful when the marketing manger steps up to give some random figures you've never heard before and don't believe.
Learning to speak the language of business will help you garner respect in your organization. An inability to do so can become a real source of frustration, and it's completely fixable.
Take Control
To resolve the problem, lay some groundwork when the project starts. You could take days or weeks to define the business side of a project before diving headlong into it. There are three key components to any project: business or marketing purpose (Why do the project?), scope and definition (What does the thing you're creating do?), and stakeholders and decision-makers (Who cares about it?).
Discovery is the process of understanding what you have to work with, where the political minefields lie, and how senior people in the company will evaluate your success. It's a way to answer important questions about the project, and an early opportunity to head off problems before they happen.
With the economy (and in particular, the Internet economy) in what appears to be a long-term downer, companies have to be careful about spending their time and money in the right places. Every day you show up to work, you're on the hook to help your company be financially stable. If you don't, you'll find yourself unemployed in a few months. The more you can explicitly describe your contribution, the more credibility you'll have.
Here's another way to look at it: We're always focused on understanding the user's needs. If a product is hard to use or visitors don't like it, the product is considered a failure. If the product doesn't also meet the needs of the business, how can you consider it a success? To be successful, a project must satisfy both the user and the business.
Discovery is a useful tool for understanding the needs and context of the business, much as other sorts of research can help you understand the users' needs and context.
Why Projects Go Awry
If you've been working on the Web for any length of time, you've either experienced or witnessed some real train wrecks. Here are the top ten ways that projects fail:
- The project gets bogged down in approvals.
- Your assumptions about project goals are way off base.
- You discover halfway through that the scope is much greater than you'd imagined.
- Feature creep. Your client continues to add little bits of functionality until you're behind schedule and over budget.
- Disenfranchised people become obstacles.
- Nobody listens to you, even though you're supposedly in charge.
- Nobody understands what you're saying, maybe because you don't have the same understanding of the project.
- Someone important and powerful (like the CEO) hates the final solution a week before launch.
- Your proposed solution can't be implemented.
The Goals of Discovery
The good news is that all of these problems can be eliminated (or at least lessened) if you use a discovery process to start strong. The four main goals of discovery are to:
- Build relationships.
- Define project criteria.
- Formulate strategies for approaching the project.
- Understand the context in which you're working.
Let's look at how to accomplish these goals.
Start at the Top
A great way to start a project is to have a one-on-one with the most senior person in the company who cares about the project, and will give you his or her time. In order for a project of any size to get approval, someone with some staff or budget had to decide it was a good idea—and possibly they had to earn their boss's approval as well. Figure out who that is; they're the person you'll need to show your work to at various points in the process. I call this person the senior sponsor of the project. That person is putting resources on the line for it, and will probably be held accountable for its success.
Obtain a one-on-one meeting with the sponsor and talk with him or her about several things: what she or he expects the project will accomplish, the business imperative, the decision process, which other departments should be included, and how you should include them.
Define the Business Mandate
At your meeting with the sponsor, ask why this project was funded. Every company is under tremendous budgetary and time constraints; at the same time, there are about a hundred projects that you could be working on right now. What does the company hope to gain that it's willing to let you do this project?
I call this the business mandate. From a business perspective, what is the compelling reason for the project that makes it worth the cost of paying people to do it? You may need to do some digging around the company to get others' input on this question. Talk to marketing or other business people as well.
Sometimes the business mandate is clearly defined ("increase click-through to this or that area by 4 percent"), and all you have to do is ask. More often, though, the business people haven't really put such a fine point on it. It's frequently just that someone has an intuitive idea that this is the right thing to do. While that's great, it isn't specific enough to suffice as a valid reason to undertake a project.
This is a good place for you to step up as a leader. Work with the business people to clearly define what the company hopes to gain from the project, in business terms. Then use that goal, along with the more user-centered design goals, to guide the project's development. At the end, you'll know whether the project is a success, and you'll be able to explain it to business people in terms that they'll respect and understand.
Outline the Decision Process
While you're talking to the project sponsor, you should also try to sketch out a picture of how decisions will be made on the project. Exactly who will be involved, what are the milestones at which decisions must be made, how much time does the sponsor need to review deliverables, will email suffice or are review meetings necessary? You want a list of decision makers, a clear description of which steps you must take to get decisions made, and a commitment about how long it will take to make them.
Many projects are derailed because the decision process takes a week at every review point, when you only expected it to take a day. Or because some big shot sees your comps at the end of the project and decides that she or he hates them, and suddenly you're back to the drawing board.
Figure out who has the final authority, who else needs to be involved in the decisions, how those people like to be communicated with, and how long they need to make a decision. Then put all of that insight into your project plan.
Possibly you've been told that you have autonomy, that this project is your baby and you're fully empowered to make the calls. While that may be true, it's always a good idea to establish occasional checkpoints with higher-ups throughout the project. These are opportunities to show progress and invite comment, even if you have complete sign-off authority. Again, this will improve your credibility by demonstrating that you're open to input.
Identify the Stakeholders
As early as possible, begin to identify the stakeholders for your project. This is a handy piece of jargon that that simply means "the people who care about the thing you're about to do." These can be all sorts of people: the engineers who will be implementing it, the marketing managers whose products will sell depending upon your project's success, and so on.
Look for anyone whose job will be affected by the project. Make a list of those people—you're going to want to involve them early, consult with them periodically, and give them a say in the final solution. These people may not necessarily want to be actively involved, but you'll gain a lot of credibility simply by giving them the option to participate.
As you look for stakeholders and begin talking to people, keep an eye out for people who are enthusiastic about the project. One of the most important aspects of the stakeholder group is that it can help you. Most projects are understaffed. Having supportive stakeholders will move you to a better, stronger, more successful solution more quickly.
At the same time, also notice where there might be political tension or friction. Usually you'll find a bit of this, and it's always best to know about it early, so that you don't stumble into a thicket of trouble later.
Hold a Kickoff Meeting
One of the primary advantages of discovery is that you start building relationships with all of the people who can make or break your project. Once you know who the stakeholders are, and roughly what the project goal is, pull everyone together for a kickoff meeting. This is your chance to introduce yourself, set expectations, and get everyone thinking along the same lines.
At this meeting, explain who you are and what you do. Go around the room and ask each stakeholder to introduce him or herself. If everyone already knows each other, focus on the interest in the project. This is your opportunity to get acquainted with the people who will be involved, so listen carefully to what your stakeholders have to say.
Explain the project, the goals, the business imperative, and the user-centered design objectives. Go over the mechanics of the project—the process, schedule, deliverables, team. Next, explain how the stakeholders will be involved. How will they be allowed, or expected, to contribute to your process? How will they be included as the work progresses? How much influence will they have over the final decision? (You may need to be diplomatic here.)
The idea is to make everyone excited and enthusiastic. You want their support and their help—or at least a neutral, cooperative disregard. Above all, setting up and holding this meeting should help you to establish relationships with these folks. That counts for a lot when you're working hard toward a deadline.
Define Project Criteria
The discovery process so far has gone like this: meet with the top brass, figure out who your stakeholders are, get to know them a bit, and hold a kickoff meeting.
As you proceed through these steps, try to develop a common understanding of the project's scope and the definition of what exactly the end product needs to be. This is less about you telling others how it is, and more about evolving ideas together. Sometimes you'll need to be persuasive and firm, other times you'll need to listen and adjust your thinking. And that's fine. That's why this is called discovery, because you want to discover as much as you can before you start thinking up a solution.
Once the scope and definition are fairly clear in your mind, make sure all of the stakeholders and decision makers have it clear in their minds too. This means mentioning it explicitly during conversations, writing it down formally in project plans and specifications, and reiterating it in emails. Sometimes, through no fault of anyone's, people fail to understand each other.
As a leader who is interested in the project's business success, you need to care about whether everyone has the same understanding of the what, why, and how of the project.
Understand the Technologies
As you move through the discovery process, you'll also be able to sketch out the technological constraints under which you'll be working. What systems will you be hooking into? Which new systems will be coming online that you can leverage? What sort of support can you obtain from the engineering or database teams? Once you've explored these questions, write them up as a technical brief that can be shared with other team members. By involving the technology stakeholders early, you'll not only gain their support, but you'll also start the project on more realistic footing.
Formulate Strategies and Write a Plan
Throughout all of this research and conversation, you'll come to understand what resources you need, what methods to use, the process you'll go through, and how long it will take. If you need to ask for a budget, understanding the project scope and definitions will make your estimates more accurate.
The deliverables that come out of the discovery process will vary. For large projects, you may want to be fairly formal; for small projects, a couple of pages are plenty. Regardless of the length, you should always summarize your findings for distribution to the stakeholders and the senior sponsor. This lets people review what will be done and ask clarifying questions.
In some cases, it may be appropriate to gather previous research or project documentation. Including a brief summary of those findings can be very useful. This summary will help you to leverage prior work—and it's always good to show management that their prior investments are being put to good use.
Distribute a project plan or brief to the stakeholders and the decision makers that includes notes on what you've learned. It should at least include: sponsor and decision makers, stakeholders, team, business mandates, mandatory features, assumptions, process overview, definitions, schedule, and budget.
Come in on Target
As you move into the design and development phase of the project, the information you gathered during discovery will help you to avoid the most common pitfalls. Periodically, read back through the original goals and documents that you created. This will help you keep business objectives in mind during times when the user's goals are your primary concern. Remember, in the end, the project you're working on must support the business, or you'll all end up out of work.
Along the way, you may find it necessary to adjust the original goals and project criteria. That's no problem, just be sure to work out those changes with the senior sponsor and your most important stakeholders.
As you approach launch, check in to make sure that you've achieved what you set out to do. In the end, designers who demonstrate that their products are effective for both the customer and the business are more likely to have credibility with management. This means that they not only listen to you, but are more likely to support your projects with budget and resources.
Janice is a partner with Adaptive Path, a San Francisco-based user experience consulting firm. She teaches interaction design at SFSU's Multimedia Studies program. Lane Becker contributed to this article. Lane is also a partner at Adaptive Path.
