As I mentioned in a previous post, it’s been my experience that — left to chance — it’s only natural that teams will stray from vision and goals. Helping teams paddle in the same direction requires not only good vision and goals, but also leadership, and intentional facilitation.
In this post we will argue that – while Strategists are not expected to fully manage design projects in their area of responsibility – there are some Project Management skills that will prove invaluable for their effectiveness, like:
- Provide vision and direction,
- Coach/mentor team members,
- Negotiation, Issue and Conflict resolution,
- Effective decision making,
- Communication and Stakeholder Management.
- The Need for Project Management
- Strategy versus Planning
- Provide Vision and Direction
- The Importance of Vision in Project Management
- Project Management and Providing Direction
- Vision versus Goals
- Qualities of Good Project Management
- Strategy and Creating Project Plans
- Facilitating Investment Discussions
- Estimating Time in Project Management
- Project Management, Scope and Agile
- Coach/mentor Team Members
- Negotiation, Issue and Conflict Resolution
- Effective Decision Making
- Communication and Stakeholder Management
- Just Enough Planning in Project Management
- Design Strategist Multiplication Program
- Recommended Reading
- Project management is about how to translate design strategies and processes into a finished result.
- Planning exercises arguably makes for more thoughtful and thorough budgets. However, planning must not be confused with strategy. Planning typically isn’t explicit about what the organization chooses not to do and why. It does not question assumptions.
- A successful project manager has the ability to translate organization vision into a project vision.
- A successful project manager has the ability to keep projects moving toward successful completion in the face of aggressive schedules and discouraging developments.
- The more freedom you have, the more structure you need.
- If designers want to influence the decisions that shape strategy — they must step up to the plate and become skilled facilitators that respond, prod, encourage, guide, coach and teach as they guide individuals and groups to make decisions that are critical in the business world though effective processes.
- The single most important thing you can do to improve communication between you and your stakeholders is to improve those relationships, earn trust, and establish rapport.
- Good project managers are flexible and yet remain objective, balanced and realistic in how they respond to the client and design challenges that arise.
- As to how to put some of these project management best practices in place:
- Find an area you can influence that could benefit from some structure: If nothing else, design strategists should project management their area of responsibility (e.g.: research and concept, design thinking, etc.) and lead by example.
- Instead of going from no-project-management-capability to a six-sigma-black-belt-certification, find a balance of just enough planning to begin with
The Need for Project Management
The Bible tells us a story about project management meltdown of historic proportions. Nimrod, the son of Cush, ‘was the first heroic warrior on earth. ‘ (Genesis 10:8),’He built his kingdom in the land of Babylonia, with the cities of Babylon, Erech, Akkad, and Calneh. ‘ (Genesis 10:10). Even you’re not familiar with Nimron, you most likely have heard of a project he tried to execute: the Tower of Babel.
According to the story, a united human race in the generations following the Great Flood, speaking a single language and migrating eastward, comes to the land of Shinar. Under the leadership of Nimrod, they agree to build a city and a tower tall enough to reach heaven. God, observing their city and tower, confounds their speech so that they can no longer understand each other, and scatters them around the world (Wikipedia contributors, Tower of Babel, 2021).
The Bible does not use the term project management, nor does it dwell on the importance of effective communications in managing large multidisciplinary project. The Bible, after all, is more interested in building worthy souls than worthy building. Nevertheless, the Bible is clear: the inability of the design and construction teams to successfully communicate destroyed the Tower of Babel (Ramroth, W., Project Management for Design Professionals, 2006).
From a design management perspective, project management is about how to translate design strategies and processes into a finished result. This entails planning and coordinating the people, stakeholders and resources necessary to get the project built, on time and within a budget (Best, K., Design management: Managing design strategy, process and implementation, 2019).
That said, this post is not to exhaust the topic of project management since in most organizations Strategists are not expected to fully manage design projects in their area of responsibility. We’ll just make the case about some Project Management skills that will prove invaluable for design strategists’ effectiveness.
Strategy versus Planning
Virtually every time the word “strategy” is used, it is paired with some form of the word “plan,” as in the process of “strategic planning” or the resulting “strategic plan.” The subtle slide from strategy to planning occurs because planning is a thoroughly doable and comfortable exercise. Strategic plans all tend to look pretty much the same. They usually have three major parts (Martin, R., The big lie of strategic planning, 2014):
- The first is a vision or mission statement that sets out a relatively lofty and aspirational goal.
- The second is a list of initiatives—such as product launches, geographic expansions, and construction projects—that the organization will carry out in pursuit of the goal.
- This part of the strategic plan tends to be very organized but also very long. The length of the list is generally constrained only by affordability.
Planning exercises arguably makes for more thoughtful and thorough budgets. However, it must not be confused with strategy. Planning typically isn’t explicit about what the organization chooses not to do and why. It does not question assumptions. And its dominant logic is affordability; the plan consists of whichever initiatives fit the company’s resources (Martin, R.,The big lie of strategic planning, 2014).
It is crucial that designers engage with their business stakeholders to understand what objectives and unique positions they want their products to assume in the industry, and the choices that are making in order to achieve such objectives and positions.
Mistaking planning for strategy is a common trap. Even board members, who are supposed to be keeping managers honest about strategy, fall into it. They are, after all, primarily current or former managers, who find it safer to supervise planning than to encourage strategic choice (Martin, R.,The big lie of strategic planning, 2014).
Strategy and the Need of Planning
Solid, practiced project management skills are critical to everyone, whether you’re a full-time project manager or absorbing the role for your project team. To fully understand how you can best serve in that role, consider the following guidelines (Harned, B., Project Management for Humans, 2017):
- What does the role mean to your team, and what can you do to uphold it?
- How do you look for project risks and act on them with confidence before they become bigger issues?
- How can you be an honest, direct communicator for the sake of your team and clients?
- How can you be open to learning and adapting to people, situations, and projects?
- What does it take to embrace all of the tasks that fall to your role, such as estimating projects, creating plans, managing scope, motivating teams, and so on?
- Can you stick to your guns and do what is best not only for you, but also for the project?
Structure is needed to keep teams from devolving or losing focus, especially when facing complex challenges. By understanding how ideas develop and setting up cycles of effort that are timeboxed and iterative, you can help teams de-risk situations and learn to reduce or avoid negative consequences that come from their solutions (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019).
The structure you create isn’t meant to govern exactly what teams do or function as a monolithic order, but rather to help the core team and their stakeholders be explicit about where they are in their efforts and manage expectations. Plans should be made visible and revisited periodically to see what’s changed and whether the effort needs a different approach (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019).
While Strategists are not expected to fully manage design projects in their area of responsibility – there are some Project Management skills that will prove invaluable for their effectiveness, like (Udo, N., & Koppensteiner, S. What are the core competencies of a successful project manager? 2004):
- Provide vision and direction,
- Coach/mentor team members,
- Negotiation, Issue and Conflict resolution,
- Effective decision making,
- Communication and Stakeholder Management.
Provide Vision and Direction
Have you ever been part of a team that didn’t seem to make any progress? Maybe the group had plenty of talent, resources and opportunities, and team members got along, but the group never went anywhere? If you have, there is a strong possibility that the situation was caused by the lack of vision (Maxwell, J. C., The 17 indisputable laws of teamwork, 2013).
In the second post of this series, I’ve mentioned that I’ve found that — more often than not — is not for the lack of ideas that teams cannot innovate, but because of all the friction or drag created by not having a shared vision and understanding of what the problems they are trying to solve.
Just to make sure I’m not misunderstood — as my colleague Anton Fischer usually says — it doesn’t matter at that point if the team lacks a vision or the vision is just poorly communicated, the result is the same: team will lack engagement and slowly drift apart.
The Importance of Vision in Project Management
A global study conducted in 2012 involving 300,000 employees found that just over half did not really understand the basics of their organizations’ strategies (Zook, C., & Allen, J., Repeatability, 2012). Given the effort applied to strategy development, there is a massive disconnect here. The opportunity to reconnect a firm with its strategy lies in how the strategy is communicated and understood (Callahan, S., Putting Stories to Work, 2016).
The design team needs to assess the extend to which the challenge at hand is driven by a vision that is shared by asking three questions (Calabretta, G., Erp, J. V., Hille, M., “Designing Transitions: Pivoting Complex Innovation” in Strategic Design, 2016):
- Is there a project vision? Does the company have a clear view of the project direction, and where it fits into the raison d’être (the “why”) of the company? How exactly will the project help the company fulfill it’s why? A satisfactory answer to this question should emerge during the early stages of a strategic project, when the brief is formulated. Lack of clear-cut answer to these questions usually signals the absence of a strong, cohesive project vision.
- Is the project a good fit with the wider goals of the organization? Sometimes the project vision does not align with the KPIs or primary goals that the organization has expressed elsewhere. This usually happens – for example – when a trend emerges and organization may act impulsively because they are afraid to miss out on what they see as an opportunity for growth.
- Is the vision shared across the company? If there is a clear project vision, is there widespread awareness and alignment within the company? Can various department move in the same direction during project setup and implementation.
As I mentioned earlier, it doesn’t matter at this point if the team lacks a vision or the vision is just poorly communicated, the result is the same: team will lack engagement and slowly drift apart. I believe designers should step up to the plate and work with stakeholders to facilitate the the discussions that will better communicate the vision or create one is it is lacking.
Project Management and Providing Direction
Making sure organizations and designers share the same vision is crucial to the success of any design project. A “shared project vision” means (Calabretta, G., Erp, J. V., Hille, M., “Designing Transitions: Pivoting Complex Innovation” in Strategic Design, 2016):
- There is widespread clarity in the stakeholders’ and designers’ understanding of the project goals and direction.
- There is widespread clarity in the stakeholders’ and designers’ understanding in the approach taken during project implementation.
At the heart of a vision should be answers to many questions. Some of these questions are intentionally similar to questions asked during planning. The difference is that these questions are angled heavily toward priorities and decisions. During planning, there can be room for exploration, but the vision is obligated to take a stand and be decisive (Berkun, S., Making things happen, 2008):
- What is the one sentence that defines this specific of this specific project/ product? Check how to write product vision.
- How does this project contribute to the goals of the organization? Why is this project more relevant than others that also might contribute to the goals of the organization?
- What scenarios/features for customers are essential to this project?
- What scenarios/features for customers are desired but not essential?
- How is this not a technology is search of a problem?
- What is this project not going to accomplish?
- What solutions for customers have been requests or suggested but will definitely not be part of this project?
- What are some of the likely ways for this particular project to fail, and how will they be avoided or minimised?
- What assumptions are being made that the project depends on? What dependencies does this project have on other projects, companies, or organizations?
While a design strategist might not necessarily come up with detailed plans of how to answer all these questions, a good facilitator can help the team probe probe, nod and coach them by asking the team to explain how they know where the project is, where it has been, and where it is going.
Vision versus Goals
Often, talk about goals refers to user goals or someone’s personal goals. While important, when you identify and define the organization’s strategy, you focus on your organization’s, department’s, or project’s goals. Eliciting goals can be as simple as asking. The problem? If you ask five people about their goals, not only do you get different goals, you get different types of goals. Three types of goals, actually (Govella, A., Collaborative Product Design: Help any team build a better experience, 2019):
- Organizational goals identify what the organization, as a whole, wants to accomplish. When you see people talk about big “S” strategy, they’re talking about organizational goals. For example, an international coffee company’s organizational goal might be to expand their customer base.
- Department or business-line goals describe what a specific department inside of an organization wants to accomplish. While an international coffee company has an organizational goal to expand the customer base, the department/business-line goals should support and enable the organizational goals. The commerce department might have a goal to improve the conversion rate for new visitors. By improving the conversion rate, the ecommerce department helps expand the customer base.
- Project goals detail what a specific project wants to accomplish. For example, the ecommerce department might kick off a project to improve personalization on the website. By improving personalization, they hope to improve conversions and expand the customer base.
Projects exists in one of two contexts (Govella, A., Collaborative Product Design: Help any team build a better experience, 2019):
- Exploring possible solutions
- Pursuing a single solution
Although collaboration structure remains the same, projects in exploration require a slightly different approach than projects working on a specific solution.
Projects in Exploration Mode
Projects in exploration mode have not decided on a solution. Not only is the solution not known, the problem may not be known. For projects in exploration mode, you imagine ways to frame problems and different ways you can solve them. Rather than working toward a solution, you are working toward an understanding and what the solution could be. If you haven’t settled on a solution and you’re trying to understand your options, then you’re exploring. You’re looking for new ways to innovate, new ways to solve a problem. In projects in exploration mode, you use collaboration to generate and explore multiple options.
Projects in Solution Mode
You have seen projects in solution mode. In these projects, the problem is known and the solution is known. For projects in solution mode, you design ways to implement the solution, iterate on those ideas, and test them. In solution mode, you Think-Make-Check your approach to the solution. In solution mode, you use collaboration to iterate and refine how you will implement the chosen solution.
Qualities of Good Project Management
Project Management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project management enables organizations to execute projects effectively and efficiently. Effective project management helps individuals, groups, and public and private organizations to (Project Management Institute, A guide to the project management body of knowledge – PMBOK guide, 2017):
- Meet business objectives;
- Satisfy stakeholder expectations;
- Be more predictable;
- Increase chances of success;
- Deliver the right products at the right time;
- Resolve problems and issues;
- Respond to risks in a timely manner;
- Optimise the use of organisational resources;
- Identify, recover, or terminate failing projects;
- Manage constraints (e.g.: scope, quality, schedule, costs, resources);
- Balance the influence of constraints on the projects (e.g.: increased scope may increase cost or schedule);
- Manage change in a better manner
Strategy and Creating Project Plans
A project plan is arguably the most important document created on your project. At its core, a plan should communicate your project approach and the process your team will use to manage the project according to scope. If handled with care and great consideration, a good plan should act as an agreement on project objectives, scope, major deliverables, milestones, timing, activities, process, and even resources needed to deliver your product. If you take the time to create a good process around how your plan is built and you consider all of those factors, you can create a great plan that will work for everyone. (Harned, B., Project Management for Humans, 2017)
Projects are the way in which human creativity is most effectively harnessed to achieve tangible, lasting results. In the past they may have been called something different, but building a pyramid, panting a ceiling, or founding a nation all required vision, planning and coordinated effort — the essential features of what we now call a project. In practical terms, just about any initiative or piece of work that is too large or unfamiliar to be completed successfully without some measure of preparation and planning can — and usually should — be approached as a project (Kindersley, D. The Book of Management, 2010).
The fact is, a plan is more than just dates. It’s the story of your project, and you don’t want it to be a tall tale! Like any well-written story, there are components that make it good. In fact, any solid plan should answer these questions (Harned, B., Project Management for Humans, 2017):
- What are the major deliverables?
- How will you get to those deliverables and the deadline?
- Who is on the project team and what role will they play in those deliverables?
- When will the team meet milestones, and when will other members of the team play a role in contributing to or providing feedback on those deliverables?
Uncertainty and Risk
Some projects have considerable uncertainty around project requirements and how to fulfill those requirements using current knowledge and technology. These uncertainties can contribute to high rates of change and project complexity. As project uncertainty increases, so too does the risk of rework and the need to use a different approach (Project Management Institute, Agile practice guide, 2017).
Planning out efforts for problems that are complex and ambiguous is tricky. The first place to start is by deciding just how complex and ambiguous your problem is. Have the team think through what they know, and what they’ve learned, about the problem and possible outcomes. Here are some questions that can help you determine how complicated your challenges are (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019):
- Are there comparable problems/solutions that exist to use as a starting point?
- Is the problem well understood, based on data, or are there only assumptions that need testing?
- What’s the worst-case scenario if a solution goes wrong? What’s at stake?
- Can effects and outcomes be scaled down and tested on a smaller population to reduce negative consequences while we learn what works?
To mitigate the impact of risks, teams select life cycles that allow them to tackle projects with high amounts of uncertainty via small increments of work. Teams can verify their work when they use small increments and can change what they do next. When teams deliver small increments, they are better able to understand the true customer requirements faster and more accurately than with a static written specification (Project Management Institute, Agile practice guide, 2017)
Predictive, Iterative, Incremental or Agile Project Management?
Projects come in many shapes and there are variety of ways to undertake them. Project teams need awareness of the characteristics and options available to select the approach most likely to be success for the situation. There are four most common life cycles (Project Management Institute, Agile practice guide, 2017):
- Predictive. A more traditional approach, with the bulk of planning occurring upfront, then executing in a single pass; a sequential process
- Iterative. An approach that allows feedback for unfinished work to improve and modify that work.
- Incremental. An approach that provides finished deliverables that the customer may be able to use immediately.
- Agile. An approach that is both iterative and incremental to refine work and deliver frequently.
The goal of project management is to produce business value in the best possible way given the current environment. It does not matter if that way is agile or predictive. The question to ask is “how can we be most successful?” (Project Management Institute, Agile practice guide, 2017):
- Is feedback needed as the team produces value? If so, increments will help. Is it necessary to manage risks as ideas are explored? If so, iterations or agile will help.
- When the organisation cannot deliver intermedia value, Agile approaches may not be useful. That is okay — agile for the sake of agile is not the goal. The point is to select a life cycle or a combination of life cycles that work for the project, the risks, and the culture.
Facilitating Investment Discussions
I’ve seen too many teams that a lot of their decisions seem to be driven by the question “What can we implement with least effort” or “What are we able to implement”, not by the question “what brings value to the user”.
From a user-centered perspective, the most crucial pivot that needs to happen in the conversation between designers and business stakeholders is the framing of value:
- Business value
- User value
- Value to designers (sense of self-realisation? Did I impact someone’s life in a positive way?)
The mistake I’ve seen many designers make is to look at prioritisation discussion as a zero-sum game: our user centered design tools set may have focused too much on needs of the user, at the expense of business needs and technological constraints.
To understand the risk and uncertainty of your idea you need to ask: “What are all the things that need to be true for this idea to work?” This will allow you to identify all three types of hypotheses underlying a business idea: desirability, feasibility, and viability (Bland, D. J., & Osterwalder, A., Testing business ideas, 2020):
- Desirability (do they want this?) relates to the risk that the market a business is targeting is too small; that too few customers want the value proposition; or that the company can’t reach, acquire, and retain targeted customers.
- Feasibility (Can we do this?) relates to the risk that a business can’t manage, scale, or get access to key resources (technology, IP, brand, etc.). This is isn’t just technical feasibility; we also look need to look at overall regulatory, policy, and governance that would prevent you from making your solution a success.
- Viability (Should we do this?) relates to the risk that a business cannot generate more revenue than costs (revenue stream and cost stream). While customers may want your solution (desirable) and you can build it (feasible), perhaps there’s not enough of a market for it or people won’t pay enough for it.
Design strategists should help team find objective ways to value design ideas/ approaches/ solutions to justify the investment on them from both desirability, feasibility and viability.
Estimating Time in Project Management
ronBeing able to estimate the amount of time required for the tasks and activities of a project is a key skill for any project manager. Indeed, in smaller projects that do not have an explicit budget, keeping to time is likely to be on fo the measures of your effectives project manager (Kindersley, D. The Book of Management, 2010)
How to estimate the time required (Kindersley, D. The Book of Management, 2010):
- Break down tasks until you know precisely who is doing what
- Involve the person who will be doing the tasks in deciding how long it will take
- Seek advice from those that have done similar tasks before
- Use a time estimation formula
Using a time estimation formula
Different organizations, industries, and sectors employ different models or formulae to estimate time. At first sight they always seem mathematical, but in most cases their effectiveness is psychological — either overcoming aversion to estimating, or encouraging more careful thought in those who tend to rush in. Perhaps the most widely known is the PERT formula (Project Evaluation and Review Technique). To use PERT you need three estimates of the time it could take to complete a task or activity (Kindersley, D. The Book of Management, 2010):
- The most likely time required (Tm)
- The most optimistic time assessment (To)
- The most pessimistic time assessment (Tp)
Using the following formula to estimate the most probable duration for that activity (Te)
Te = (To + 4Tm + Tp)/6
The formula can be weighted toward pessimism — if the consequences of late completion of a particular task are sever, for example — by reducing the Tm multiplier and adding a Tp multiplier.
Te = (To + 3Tm + 2Tp)/6
That said, even the most experienced engineer (or designer, or architect, etc) needs to deal with uncertainty by acknowledging that even our best estimates can be based on only assumptions.
- Estimations are more useful for representing agreement, not reality: put the numbers in, compare and learn from other estimators, assess what can we agree on, commit and move on.
- One only can only estimate on work he/she has actually done: if you’ve never done this kind of work, acknowledge it, produce our best guesses, monitor the progress of work, compare estimations with the reality once implementation happens (that’s when the traceability and visibility aspect of the Quantifying and Qualifying Strategy framework comes in), and you’ll will get better with practice.
- We should never commit to estimations without consulting the person responsible or affected by the work: when assessing things like “T-Shirt sizes”, “Business Value”, or “Effort”, have your first pass but keep in mind that you’ll need to confirm and agree on the estimates with whoever are responsible or affected by the work before communicating you decisions.
Timeboxing Over Deadlines
One way to deal with the pressure to get to the answer quickly and short-circuit the process is timeboxing, or defining a set amount of time for an activity versus a specific outcome. This helps keep the momentum of the team going, and get them trying out ideas to gain feedback and data about what works to show progress instead of jumping to the end (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019).
Timeboxing must be very explicit and made transparent to everyone. You may want to just timebox a stage in the process, or run the entire cycle as a single sprint, working fast and loose to see what gets unstuck. What’s key is that you don’t skip stages or squish them too far. And, when you reach the end of your timebox, you can always add “extra time” if you aren’t quite finished (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019).
Project Management, Scope and Agile
When planning and managing a project, you will often be hit by constraints. You will work with limited resources (especially budget or access to people), with tough deadlines and an ambitious scope or objectives. To make things worse, those constraints will influence each other (Stickdorn, M. et al, This is Service Design Doing, 2018)
In many traditional projects the scope is fixed. That works well if the scope is built around a deterministic challenge. But every time you discover it is not as defined as you thought, the approach becomes painful. You can either hurriedly add more resources in an attempt to fix it — making it more expensive — or you might have to shift the delivery date, putting a dent in your reputation as a project manager. (Stickdorn, M. et al, This is Service Design Doing, 2018).
Specifically, this approach does not work in many forms of digital product development and/or service design, where you often challenge and change the scope of a project right from the start by “Making sure you solve the right problem before solving the problem right”. (Stickdorn, M. et al, This is Service Design Doing, 2018).
This challenging and chaining the scope right from the start poses a new problem: if you are dealing with complex challenges it is now very easy to lose track of all the different insights, opportunities, or ideas. You will soon waste a lot of time and resources, and your team might start to pull in different directions (Stickdorn, M. et al, This is Service Design Doing, 2018).
Keeping the scope variable adds a high degree of freedom to your project that needs to be managed very carefully. You will need to add structure which will allow for the necessary freedom in scope while letting you plan and manage the process (Stickdorn, M. et al, This is Service Design Doing, 2018).
Working against a Fixed Deadline
Its not always possible to predict how long it will take a team to tackle a complex problem with a lot of unknowns, and there will be times when a critical deadline must be met. In this situation, teams try to argue against the deadline and ask for more time, and never seen it work. Or, teams agree to a deadline with unrealistic expectations, only to miss it and suffer the consequences. In the situation where there is a key date that must be met, but not enough information to know how to get there, you run the risk of putting the group in jeopardy if you don’t work to get more clarity. Here are a few ideas to get more clarity (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019):
- Define partial success: To avoid having the collaboration get crushed under the weight of unreasonable expectations, focus instead on how you can get part of the way there, expressed in business terms, not features. If “sign up 2,000 paying customers” is what keeps the company afloat in three months, think about what you can do to get some of those financial results, rather than listing partial capabilities. In Lean UX (‘Reilly), Jeff Gothelf and Josh Seiden do a great job of laying out how to think outside the box to get results without overly committing to work that won’t pay the full dividend in time.
- Define the worst-case scenario: It can be hard to be the person who speaks the truth about an ugly out come. Early in my career, I faced extreme pressure to “be flexible” and agree to a client’s demands even though they put their business at great risk. When the inevitable blow-up happened, it wasn’t just unpleasant — several of my clients lost their jobs and the company eventually folded. The bad outcome that most of my team were focused on was displeasing the client, when in fact the worst case was so much worse than that. If you feel you’ve been given an impossible mandate, you owe it to yourself and others to make sure everyone understands what happens if (even though you know it’s a “when”) the team’s efforts aren’t totally successful.
- Delay the “work” in favour of workarounds: While it might not be the most efficient way to get work done, if there really is a critical deadline, it may be better to develop a Band- Aid solution Art. You will need to buy time later to create a real solution, but that will be easier to argue for when you’ve already met key requirements.
Scope, Requirements Management and Agile
In the current environment that most technology companies in which words like “requirements” might sound so old-fashioned and not “agile”, I feel strongly the unintended consequence in attempting to create autonomous teams was that we’ve traded good stewardship principles of project management (like requirements managements, scoping, risk analysis) by complete chaos.
That said, we do need to acknowledge the limitations of requirement thinking.
Amazon has decreased their time to market to one second. That’s right: every second some Amazon customer somewhere in their ecosystem experiences a change to the way the product works. Sixty times per minute, Amazon has an opportunity to learn how well they’re meeting the needs of their customers. Sixty times per minute, they have an opportunity to respond to what they’re learning. Sixty times per minute, they have an opportunity to make their user experience better. With this capability, the very idea of a rigid requirement is, at best, anachronistic. At worst, it’s an impediment that prevents teams from doing their best work (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).
So what should we do? We need to recognize that most requirements are simply assumptions expressed with authority. If we remove the authority, overconfidence, and arrogance from the conversation, we’re left with someone’s best guess about how to best achieve a user goal or solve a business problem. We are makers of digital products, so humbly admitting that these are indeed our best guesses or assumptions immediately and explicitly creates the space for product discovery and Lean UX to take place (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).
We reduce our attachment to the ideas and create a team culture that is more willing to adjust course–even to stop working on an idea that continues to prove unviable (Gothelf, J., & Seiden, J., Lean UX: Applying lean principles to improve user experience, 2021).
When thinking of creating a learning culture, it help to focus on the collective behaviors of a system, and the “constraints” of that system inform and shape that behavior. Constraints shape a system by modifying its phase space (its range of possible actions) or the probability distribution (the likelihood) of events and movements within that space. Because constraints are both key actors and key indicators of a system, constraint mapping can be a highly productive first step in considering how to intervene (Juarrero, A., Dynamics in Action: Intentional Behavior as a Complex System, 1999)
Designing effective enabling constraints is an art. Many things feel intuitively correct, but have potentially harmful consequences. For example (Cutler, J. Making things better with enabling constraints, 2022):
- In an effort to increase certainty about plans and commitments, the team undertakes a comprehensive annual planning effort. This feels good on the surface, but it forces premature convergence, encourages over-utilization of shared resources, and encourages big, inflexible projects.
- In an effort to centralize communication, the team adopts a single tool for documentation (a theoretically enabling constraint). This feels good on the surface—having documentation everywhere is painful—but since a large % of communication with external teams happens outside the central tool, you find a two or three (or more) tiered system of communication (e.g. executive communication happens in slides, not in the tool).
The trick, then, is designing effective enabling constraints. An additional layer to consider is the layer of trust, respect, empowerment, and psychological safety. Example: deadlines. In theory, deadlines can be enabling constraints. However, without empowerment and trust, deadlines become disabling. Teams cut the wrong corners, and optimize for low trust. These two points—the counterintuitive nature of constraints, and the trust/safety element—explain why most change efforts fail. High trust environments can easily pick the wrong constraints. Or they try too much at once, and put people in a state of change overload (Cutler, J. Making things better with enabling constraints, 2022).
No enabling constraint is guaranteed to work, but some are better than others. What should someone designing an enabling constraint look out for? (Cutler, J. Making things better with enabling constraints, 2022):
- It is easy to know if you are doing it or not. For example, asking everyone to use a single document repository is a bit vague. People WILL need to use other systems to document things. Do those count? What goes in it? What doesn’t? An alternative might be to run an experiment where the team commits to putting ONE document type in the centralized repository or tool. Put another way, it is within reach and achievable.
- It has an expiration date and is treated as an experiment. The best enabling constraints are treated as an experiment. The team commits to give it an honest try for a period of time. The team is promised an opportunity to weigh in on the experiment, before agreeing to extend it.
- It helps people go through the motions. If you have a future state in mind, it helps to help people go through the motions a bit and try things out. In a safe way.
- The world doesn’t end if it “fails”. Sometimes things don’t go as planned. That’s normal. The best enabling constraints fail gracefully. They are safe-to-fail probes.
- Fast feedback potential. The best enabling constraints will provide fast feedback. Experiments that last forever, with no sense if they are helping/hurting, are dangerous (or at a minimum draining, and encourage people to just work around them).
Commit to Outcomes, Not Outputs
In traditional planning, the solution provider commits to delivering specified deliverables (the scope) at a specified cost within a given time frame. This approach doesn’t work when requirement are volatile because it locks all parties into predetermined specifications that are likely to be outdated by the time the product is delivered. Instead of focusing on predetermined deliverables, agile enterprises focus on desired outcomes, such as increased revenues and increased customer loyalty (Podeswa, H., The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery, 2021)
You might be asking, “what you do mean by outcome”. Joshua Seiden defines as outcome “a change in user behaviour that drives business results.”
You can help the team and leaders to start thinking in terms of outcomes by asking three simple questions (Seiden, J., Outcomes over Output, 2019):
- What are the user and customer behaviours that drive business results? I’ve suggested in another post that facilitating discussions around Jobs to be Done can be a great way to get the team to align.
- How do we get people to do more of these things?
- How do we know we’re right? The easiest (and the hardest) way to answer that question is to design and conduct tests.
Managing by outcomes communicates to the team how they should be measuring success. A clear outcome helps a team align around the work they should be prioritizing, it helps them choose the right customer opportunities to address, and it helps them measure the impact of their experiments. Without a clear outcome, discovery work can be never-ending, fruitless, and frustrating (Torres, T., Continuous Discovery Habits, 2021).
Coach/mentor Team Members
As I mentioned in the first post of this series, we need a different kind of senior designer. We need designers working on user experience teams must first advance from a tactical designer to a strategic designer. They can not only move pixels, but translate design insights in a currency that business stakeholders can understand. After that, he or she can get teams to paddle in the same direction.
The challenge of helping teams paddle on the same direction seem to be for many reasons:
- Designers feel that projects start without a clear vision or focus which problems to solve and for who
- Our user centered design tools set may have focused too much on needs of the user, at the expense of business needs and technological constraints.
- We need to point at futures that are both desirable, profitable, and viability (“Change By Design“, Brown, T., & Katz, B., 2009).
- More often than not, is not for the lack of ideas that teams cannot innovate, but because of all the friction or drag created by not having a shared vision and understanding of what the problems they are trying to solve.
- Even the projects that do start with clear vision slow stray away as the product development lifecycle goes on
- It doesn’t matter at that point if the team lacks a vision or the vision just is poorly communicated, the result is the same: team will lack engagement and slowly drift apart.
- Designers may have naively believed that the user perspective can be provided at one point of the product development lifecycle (e.g. during project/backlog/sprint planning phase).
- In reality “any product that makes into the the world it’s actually the outcome of a set of dozens, hundreds or thousands of decisions along the way. Each decision building upon each other, informing and influencing all aspects of the user experience”. (“Elements fo User Experience: User-Centered Design for the Web and Beyond“, Garrett, 2010).
If designers want to influence the decisions that shape strategy — they must step up to the plate and become skilled facilitators that respond, prod, encourage, guide, coach and teach as they guide individuals and groups to make decisions that are critical in the business world though effective processes.
In my experience, the biggest disconnect between the work designers need to do and the mindset of every other team member in a team is usually about how quickly we tend — when not facilitated — to jump to solutions instead of contemplate and explore the problem space a little longer.
I’m of the opinion that designers — instead of complaining that everyone else is jumping too quickly into solutions — should facilitate the discussions and help others raise the awareness around the creative and problem solving process.
From that perspective, I find it incredibly important that designers need to ask good questions that foster divergent thinking, explore multiple solutions, and — probably the most critical — help teams converge and align on the direction they should go (Gray, D., Brown, S., & Macanufo, J., “What is a Game?” in Gamestorming, 2010).
Knowing when team should be diverging, when they should be exploring, and when they should closing will help ensure they get the best out of their collective brainstorming and the power multiple perspectives to keep the team engaged.
Strategy Decisions and the Need for Facilitation
No matter what kind of organization, team structure, or project types you’ve worked on, you’ve probably had experienced problems working with teams, such as:
- drifting focus
- misunderstood communications
- uneven participation
- struggles for power and control
- difficulties reaching consensus
- frustrations with obtaining commitment to follow up action.
This is not by ill-intent: Patrick Lencioni posits that making a team high performing – i.e. high-functioning, collaborative, cohesive, aspiring, engaging – requires self-discipline, courage and stamina (Lencioni, P. M., Overcoming the five dysfunctions of a team, 2011).
Facilitation is a deceptively familiar word, because it sounds like something you know, but means different things in different workplaces. For the purposes of this conversation, a definition of facilitation consists of two things (Hoffman, K. M., Meeting Design: For Managers, Makers, and Everyone, 2018):
- Facilitation is an explicitly designated role for managing conflict. That role is filled by a single individual, or multiple individuals when you have multiple small groups, with each group having its own facilitator.
- Facilitators create a productive pattern of conversation, built on divergence and convergence. This pattern encourages tangents, but also manages tangents to direct the conversation toward decisions.
It’s been my experience that — left to chance — it’s only natural that teams will stray from vision and goals. Helping teams paddle in the same direction requires not only good vision and goals, but also leadership, and intentional facilitation.
Facilitators are here to enable groups to succeed by (Smutny, M., Thrive: The Facilitator’s Guide to Radically Inclusive Meetings, 2019):
- Asking questions. Creative questions allow a composite picture of the organization to emerge before a strategy event. This listening prepares the consultant to facilitate with knowledge and skills.
- Designing a planning process that is unique to the team they are working with. An experienced facilitator creates a meeting designs from a wealth of methods, tailored to the objectives to the team.
- Helping the group get specific action plans. She or he will not let teams get stuck with vague generalities.
Negotiation, Issue and Conflict Resolution
In a collaborative environment, Design is a process of negotiating among disciplines. Solutions are not only based on purely technical problem solving criteria. They also result from compromises between designers: solutions are negotiated (Bucciarelli, 1988). Therefore, it is important to establish common ground and negotiation mechanisms in order to manage the integration of multiple perspectives in design (Détienne, 2006).
Given the collaboration required to generate shared understanding, conflicts can emerge from disagreements between designers and other stakeholders about proposed designs. Hence, a critical element of collaborative design is to manage the detected conflicts and particularly the impacts once they are resolved (Ouertani, 2008).
When I talk about conflict on a team, I’m talking about productive, ideological conflict: passionate, unfiltered debate around issues of importance to the team. Any team that wants to maximise its effectiveness needs to learn to do this, and doing so can only happen if vulnerability-based trust exists (Lencioni, P. M., The five dysfunctions of a team, 2013). We will come back to trust later.
While conflict is natural, we need to step up to the plate with a non-judgemental attitude towards our team, always expecting the best and –– in a counter intuitive way –– not anticipate conflicts.
The Gift of Disagreement
Truth 1: Arguments aren’t bad. They are signposts to issues that need our attention.
Truth 2: Arguments aren’t about changing minds. They are about brining minds together.
Truth 3: Arguments don’t end. They have deep roots and will pop up back again and again, asking us to engage with them.
Done right, arguments are opportunities. A productive disagreement is something you’ll look forward to rather than dread. It’s one that leads to mutually beneficial outcome. A productive disagreement yields fruit (Benson, B., Why Are We Yelling?: The Art of Productive Disagreement. 2019):
- The fruit of security: by removing a threat, reducing a risk, resulting in a dial, or concluding with a decision.
- The fruit of growth: be revealing new information about the world or each other that makes us see and understand reality more deeply;
- The fruit of connection: by bringing us together and giving us opportunities to forge trust with one another;
- The fruit of enjoyment: by teaching us to operate with collaborative mind-set that emphasizes playfulness, adventure, fun, and sometimes even awe.
How do you assess a conversation to be sure you can handle it properly, especially when every individual perceives these exchanges differently? There is a lot that goes into any conversation—difficult or otherwise—but keep in mind that if you initiate the conversation, you’ll want to think through every possible argument, statement, or outcome before you even speak a word about it. Your assessment won’t always be correct, but dissecting the factors that will play into your conversation will help you understand the situation and the other person (or people) better—and conduct it like a professional. (Harned, B., Project Management for Humans, 2017)
Negotiation and Conflict Handling
I’ve noticed in my own experience — but also observing how junior designers conduct themselves — is that we usually tend to bargain over positions (e.g.: “from a user experience perspective, this works best because….”), thinking that if we bring enough knowledge to the table or make strong enough arguments, designers would convince the team about the way to move forward. This idea of “Bargaining over positions” (through persuasion) comes with shortcomings that we are – more often than not – not even aware of since most of us were not trained with the emotional intelligence it takes to deal with conflict in a healthy way.
Meyer again brings clarity also on way persuading might prove to be difficult in trans-cultural teams (Meyer, E., “Why versus How: The Art of Persuasion in a Multicultural World” in The Culture Map: Breaking through the Invisible Boundaries of Global Business, 2014):
- some cultures tend to be Concept-first: individuals have been trained to first develop the theory or complex concept before presenting a fact, statement or opinion)
- while others tend to be Application-first: individuals are trained to begin with a fact, statement, or opinion and later add concept to back up or explain the conclusion as necessary.
From that perspective, another challenge that arises while negotiating comes from the fact that the way most negotiation strategies fail because they start arguing over positions (Fisher, R., & Ury, W., Getting to Yes: Negotiating an agreement without giving in, 2012):
- Arguing over positions produces unwise outcomes: we tend to lock ourselves in those positions. The more you clarify your position and defend it against attacks, the more committed you become to it. The more you try to convince “the other side” of the impossibility of changing your position, the more difficult it becomes to do so.
- Arguing over positions endangers an ongoing relationship: positional bargaining becomes a contest of will. Each side tries through sheer willpower to force the other to change its position. Anger and resentment often results as one side sees itself bending to the rigid will of the other while its own legitimate concerns go undressed. Positional bargaining thus strains and sometimes shatters the relationship between the parties.
- Where there are many parties, positional bargaining is even worse: although it is convenient to discuss in terms of two persons, you and the “other side”, in fact, almost every negotiation involves more than two persons. The more people involved in the negotiation, the more serious the drawbacks of positional bargaining.
- Being nice is no answer: many people recognise the high costs of hard positional bargaining, particularly on the parties and their relationship. They hope to avoid them by following a more gentle style of negotiation. Instead of seeing the other side as adversaries, they prefer to see them as friends. Rather than emphasising a goal of victory, they emphasise the necessity of reaching agreement. In a soft negotiating game the standard move are to make offers and concessions, to trust the other side, to be friendly, and to yield as necessary to avoid confrontation. Pursuing a soft and friendly form of positional bargaining makes you vulnerable to someone who plays a hard game.
One approach to get more constructive conflict handling is to change the game from arguing over positions to negotiating on merits (Fisher, R., & Ury, W., Getting to Yes: Negotiating an agreement without giving in, 2012):
- Principled: participants are problem-solvers whose goal is a wise outcomes reached efficiently and amicable.
- Separate the people from the problem: be soft on the people, hard on the problem; proceed independent of trust
- Focus on interests, not positions: explore interests, avoid having a bottom line.
- Invent options for mutual gain: generate alternatives to choose from; decide later.
- Insist on using objective criteria: try to reach a result based on stands independent of will; reason and be open to reason; yield to principle, not pressure.
As negotiators, different people will have different interests and styles of communication. Different things may be persuasive to them, and they may have different ways of making decisions. How should we accommodate such similarities and differences in negotiating with different people? Here are some suggested guidelines (Fisher, R., & Ury, W., Getting to Yes: Negotiating an agreement without giving in, 2012):
- Get in step. In any negotiation it is highly desirable to be sensitive to the values, perceptions, concerns, norms of behavior, and mood of those with whom you are dealing. Adapt your behavior accordingly. If you are negotiating with someone, it is that person whom you are trying to affect. The more successfully you can get in step with that person’s way of thinking, the more likely you are to be able to work out an agreement.
- Adapt this general advice to the specific situation. These guidelines offer general advice. It will not apply in the same way in every circumstance with every person. But the basic propositions are generally applicable. Absent a compelling reason to do otherwise, we advise crafting your specific approach to every negotiation around them. The best way to implement these general principles will depend on the specific context. Consider where you are, with whom you are dealing, customs of the industry, past experience with this negotiator, and so on, in crafting an approach to fit the situation.
- Pay attention to differences of belief and custom, but avoid stereotyping individuals. Different groups and places have different customs and beliefs. Know and respect them, but beware of making assumptions about individuals. The attitudes, interests, and other characteristics of an individual are often quite different from those of a group to which they may belong. Making assumptions about someone based on their group characteristics is insulting, as well as factually risky. It denies that person his or her individuality. We do not assume that our beliefs and habits are dictated by the groups in which we happen to fit; to imply as much of others is demeaning. Each of us is affected by myriad aspects of our environment and upbringing, our culture and group identity, but in no individually predictable way.
- Question your assumptions; listen actively. Whatever assumption you make about others -whether you assume they are just like you or totally different – question it. Be open to learning that they are quite unlike what you expected. The wide variations among cultures provide clues as to the kind of differences for which you should be looking, but remember that all of us have special interests and qualities that do not fit any standard mold.
Moving away from bargaining positions to negotiate on merits is pretty much aligned with two important skills that designers must master:
- Create Great Choices: the effectiveness of the team in making good decision depends on their ability of generating alternatives.
- Facilitate Critique: when well done, critique focuses on analysing design choices against a product’s objective.
It is crucial that designers engage with their business stakeholders to understand what objectives and unique positions they want their products to assume in the industry, and the choices that are making in order to achieve such objectives and positions.
Without multiple solutions to any question, the process is highly vulnerable. Without the ability to see all the work at once, spread out, relationships will be missed, and the conversation and subsequent designs will suffer. (Buxton, B., Sketching user experiences: Getting the design right and the right design, 2007).
Conflict Management and Difficult Conversations in Project Management
Let’s not sugar-coat it: even among the best teams, conflict is always at least a little uncomfortable. No matter how clear everyone is that the conflict they are engaging is focused on issues — not personalities — it is inevitable that they will feel under some degree of personal attack. (Lencioni, P. M., “Overcoming Dysfunction #2” in Overcoming the five dysfunctions of a team, 2010).
But there’s no reason to avoid conflict. In fact, if team members are not making one another uncomfortable sometimes, if they’re never pounding one another outside their emotional comfort zones during discussions, then it is extremely likely that they’re not making the best decisions for the organization (Lencioni, P. M., “Overcoming Dysfunction #2” in Overcoming the five dysfunctions of a team, 2010).
The 5 Dysfunctions of a Team
Like it or not, all teams are potentially dysfunctional. This is inevitable because they are made up of fallible, imperfect human beings. From the basketball coach to the executive suite, politics and confusion are more the rule than the exception. However, facing dysfunction and focusing on teamwork is particularly critical at the top of an organization because the executive team sets the tone for how all employees work with one another. Fortunately, there is hope. Counter to conventional wisdom, the causes of dysfunction are both identifiable and curable. The first step toward reducing politics and confusion within your team is to understand that there are five dysfunctions to contend with, and address each that applies, one by one.(Lencioni, P. M., “A Case for Teamwork” in Overcoming the five dysfunctions of a team, 2010):
Absence of trust (i.e. unwilling to be vulnerable within the group). Members of great teams trust one another on a fundamental, emotional level, and they are comfortable being vulnerable with each other about their weaknesses, mistakes, fears and behaviours. They get to a point where they can be completely open with one another, without filters, This is essential because…
Fear of conflict (i.e. seeking artificial harmony over constructive passionate debate) … teams that trust one another are not afraid to engage in passionate dialogue around issues and decisions that are key to the organization’s success in the spirit of finding the best answers, discovering the truth, and making great decisions. This is important because…
Lack of commitment (i.e. feigning buy-in for group decisions creates ambiguity throughout the organization) .. Teams that engage in unfiltered conflict are able to achieve genuine buy-in around important decision, even when various members of the team disagree. That’s because they ensure that all opinions and ideas are on the table and considered, giving the confidence to team members that no stone has been left unturned.
Avoidance of accountability (i.e. ducking the responsibility to call peers, superiors on counterproductive behaviours which sets low standards) … teams that commit to decisions and standards of performance do not hesitate to hold one another accountable for adhering to those decisions and standards. This matters because…
Inattention to results (i.e. focusing on personal success, status and ego before team success) … teams that trust one another, engage in conflict, commit to decision, and hold one another accountable are very likely to set aside their individual needs and agendas and focus almost exclusively on what is best for the team.
Getting to Commitment in Project Management
The dictionary give two meanings for commitment: (1) an agreement or pledge to do something in the future, and (2) the state or an instance of being obligated or emotional impelled. The first is about action; the second is about emotional state. It is the second the keeps us in the realm of the personal and emotional, which is what e think commitment should mean in the context of trust (Maister, D. H., Galford, R., & Green, C, 2021).
As designers, the output of our work will only make into a product with we can get stakeholders to commit. What follows is a series of questions you can ask to help assist you on getting commitment to Strategy and Stakeholder Management (Maister, D. H., Galford, R., & Green, C, The Trusted Advisor, 2021):
- What is going to get in the way of getting this done?
- What do we intend to do about it?
- Who needs to be brought into the loop?
- Who should do what part?
- What information do we need.
- When shall we check in?
- What are the key deadlines?
A central part of building the commitment to act is carefully managing the client’s expectations about what is and what is not going to happen in solving the problem. When down well, this can build great trust by demonstrating that the advisor is knowledgeable about solving problems of this kind, and can anticipate in advance where the pitfalls and contingencies lie (Maister, D. H., Galford, R., & Green, C, “Managing Expectations” in The Trusted Advisor, 2021).
We must ensure that our clients gain a clear understanding of what they can and cannot reasonably expect from us, and of what both they and we must do. Expectations (on both sides) should be identified and understood up front. (Maister, D. H., Galford, R., & Green, C, “Managing Expectations” in The Trusted Advisor, 2021).
Clients need to be made aware of every step we are proposing to take to reach their particular goal (Maister, D. H., Galford, R., & Green, C, “Managing Expectations” in The Trusted Advisor, 2021):
- some customers might take a project that is too large or too many projects, and we need to assess their commitment to, and capability of, doing what is necessary to achieve the goal.
- some customers may even decide they don’t want to invest the time, energy, or resources necessary to make the project work. They may decide to scale back their expectations to something more realistic.
Clients should understand the specific results, outcome, or deliverable that our involvement is intended to produce, as well as the contingencies produced by their time and resource constraints. To manage expectations well, we must (Maister, D. H., Galford, R., & Green, C, “Managing Expectations” in The Trusted Advisor, 2021):
- Clearly articulate what we will do and won’t do
- Clearly articulate what the client will do and won’t do
- Define boundaries off the analysis will perform
- Check with the client about areas the client may not want us to get involved in, or any people the client does not want us to speak with
- Identify precise working arrangements
- Agree on methods and frequency of communication
- Decide who should get which reports
- Decide how often a report should be delivered
- Decide how any reports will get used
- Decide what milestones and progress reviews are needed
- Decide how success will be measured, both at the end and during the process
Project Management and Resistance to Planning
There are times when teams will resist making and committing to a plan, especially if there are many unanswered questions. There can be a fear that by creating a plan they will be held to it no matter what happens. Things almost never go according to a plan, but the process of thinking through how you will all work together is still useful (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019).
If you can’t all agree on how to approach the work, and set up points in time that others can expect to see progress, you will likely not get very far together. Here are a couple of ideas to try (Anderson, G., Mastering Collaboration: Make Working Together Less Painful and More Productive, 2019):
- You Are Here: It isn’t enough to have a timeline of the effort listing past meetings and future milestones to remind people of where the team is. You need to be clear about whether the group is open to exploring alternatives and gathering substantial input, or whether you’re showing the output of a process simply to keep people updated. Don’t try to mix those two modalities, no matter how tempting it may be. Telling people you want their input on possibilities, only to show them proposed solutions to be critiqued, is guaranteed to frustrate everyone. If you have a critical stakeholder who missed the “offer solutions” timeframe, consider making a special “traveling salesman” stop beforehand to get their input, and be clear that it isn’t likely to be reflected immediately when they attend a session to update stakeholders on progress.
- Frame it as a guess: Gretchen Anderson often coaches teams to think about planning as fortune-telling, not a commitment. You can help alleviate fear of overpromising by asking the team to guess what could happen, and framing your plans with the right level of uncertainty when sharing with stakeholders. It is useful to consistently explain and show that plans are updated and changed as situations change so that people understand that the plan isn’t a contract.
Effective Decision Making
We all want to believe that all decisions are made with care and consideration, even though we know it can’t possibly so. There is limited time and limited brain power, and not all decisions can be made equally well (Berkun, S., Making things happen: Mastering project management, 2008).
The first step to making good decisions is to stop relying (too much) on instincts and challenge our own biases. Are you aware of your own biases? Let’s find out!
(Don’t) Trust Your Instincts
Humans tend to place a lot of value on instinct. Especially as the pace of modern life forces us at times to think quickly on our feet and make immediate decision, we believe that having superior instinct helps us get along. That’s certainly true to an extend. But the problem is that sometimes we confuse instinct as a substitute for good judgement. Instincts — otherwise knowns as gut feeling or hunches — are probably wrong the vast majority of the time (King, P., The Art of Clear Thinking, 2019).
Creating great choices start by recognizing that (Riel, J., & Martin, R. L., Creating great choices. 2017):
- our thinking is implicit and rarely questioned.
- our models of the world can be influenced by forces we are unaware.
- we default to simplistic models of world and rely on basic heuristics to get through the day.
- we tend to seek out the single right answer to any given problem.
These limitations easily produce problem-solving approaches that are implicit, narrow, and flawed, they tend to create an insular mindset that discounts other people and their alternative points of view. And they tend to produce bad decisions.
Many psychologies and neuroscientists have been converging on a description of the brain’s functioning that helps us make sense of our implicit, narrow and flawed thinking. The approach involves a distinction between two kinds of thinking, one that is intuitive and automatic, and another that is reflective and rational (Thaler, R. H., & Sunstein,.”How We Think” in Nudge: Improving decisions about health, wealth and happiness, 2009):
- The Automatic System: Uncontrolled, effortless, associative, fast, unconscious, skilled.
- Reflective System: controlled, effortful, deductive, slow, self-aware, rule-following.
Instincts and Biases
In part, we fail to make good decisions because of glitches in our thinking , including deep-seated biases that produce troubling lapses in logic. Each of us fall prey to these glitches to some degree, no matter how logical or open-minded we believe ourselves to be (Riel, J., & Martin, R. L., Creating great choices. 2017).
One way to avoid such traps is — obviously — beware of such biases and keep asking questions.
With regards to biases, here are a few to be aware of (Hammond, et al. The Hidden Traps in Decision Making, 2013):
- The Anchoring Trap lead us to give disproportionate weight to the first information we receive
- The Status-quo Trap biases us towards maitaining the current situation – even when better alternatives exist
- The Sunk-Cost Trap inclines us to make choices in the way that justifies past choices, even when these were mistakes
- The Confirming-Evidence Trap leads us to seek out information supporting an existing predilection and to discount opposing information.
- The Framing Trap occurs when we misstate a problem, undermining the entire decision-making process
- The Overconfidence Trap makes us overestimate the accuracy of our forecasts
- The Prudence Trap leads us to be overcautious when we make estimates about uncertain events.
- The Recallability Trap prompts us to give undue weight to recent, dramatic events
With these biases in mind, you should ask yourself some questions before making any big decision (Berger, W., The book of beautiful questions, 2019):
- What am I inclined to believe on this particular issue? Start by trying to articulate your beliefs/biases.
- Why do I believe what I believe? The “jugular question” per Nobel Prize-winning physicist Arno Penzias, forces you to consider the basis of these beliefs.
- What would I like to be true? A “desirability bias” may lead you to thinking something is true because you want it to be true.
- What if the opposite is true? This question is inspired by “debasing” experts and Seinfeld’s George Contanza.
Systematic Approaches for Making Good Decisions in Project Management
The connection among decisions you make lies not in what you decide, but how you decide. An effective decision-making process will fulfil these six criteria (Hammond, J. S., Keeney, R. L., & Raiffa, H., Smart choices: A practical guide to making better decisions. 2015):
- It focuses on what’s important: does your decision-making process helps the team keep vision, goals and priorities in mind?
- It’s logical and consistent: in the context of work group, how repeatable is the decision-making process? how “workshopable” it is?
- It acknowledges both subjective and objective factors and blends analytical with intuitive thinking: does your decision-making process helps keep instincts and biases in check, but leverage on hunches, gut feelings and emotions when needed?
- It requires only as much information and analysis as is necessary to resolve a particular dilemma: how does your decision-making process helps you to comprehensively understand the problem, its contexts, and create choices?
- It encourages and guides the gathering of relevant information and informed opinion: how does your decision-making process helps you weigh your options without running into analysis paralysis.
Communication and Stakeholder Management
Imagine managing a project without any form of communication. Unless you’re producing something on your own for yourself, it would be wholly impossible. That’s because projects are often complicated with various layers of details, requirements, and decisions. Each step requires a new task to discuss, because it’s dependent on another task or decision—or even another person. Sure, you can make it so that all of those decisions are funneled through your favorite project management planning tool, but just a plan or a tool won’t help you complete a project successfully. You’ve got to use your most basic human skills to manage a project: communications. And it’s not just about the words coming out of your mouth or the words you type in a message. It’s about intent, tone, openness, and general comfort with the work and the people around you. It’s not easy, but you can do it. (Harned, B., Project Management for Humans, 2017).
How organizations impact Project Management
At any time in a project, there are basic questions that everyone should know the answers to. You might not always like the answers, but you and your team should know what they are. Most planning frustrations occur when there’s disagreement or ignorance about these issues (Berkun, S., Making things happen, 2008):
- Who has requirements authority? Someone has to define the requirements and get them approved by the necessary parties (client or VP). In the solo-superman case this is easy: superman will have all of the authority he wants. On a contract team there will be a client who wants strong control over the requirements and possibly the design. Lastly, a big staff team may have committees or other divisions in the corporation who will need to be served by the work (and whose approval in some way is required). There may be different people with high-level requirements authority (‘It will be a sports truck”) and low-level requirements authority (“It will get 20 mpg and have 4-wheel drive”).
- Who has design authority? Similar to requirements, someone has to define the design of the work itself. The design is different from the requirements because there are always many different possible designs to fulfill a set of requirements. Designs, also like requirements, are often negotiated between two or more parties. One person or team might be responsible for driving the design process and developing ideas (designer), and another team provides guidance and feedback on the first party’s works (VP). Note that because design skill is distributed in the universe independent of political power, people granted design authority might not be people with much design talent.
- Who has technical authority? Technical authority is defined by who gets to choose engineering approaches are used, including programming languages, development tools, and technical architecture, Many of these decisions can impact requirements, design, and budget, The difference between technical decisions and design.
Understanding the culture and principles behind how teams and stakeholders make decisions becomes critical for designers to know when, what and how to influence in order to drive design vision forward. If some team members are using principles-first logic and others are using applications-first logic to reach a decision, this can lead to conflict and inefficiency from the beginning.
When these cultural differences collide, it leads members of global teams to respond emotionally to what they see as ineffective behaviors of others on the team. Worse still, most of us are not even aware of the system of our own culture uses to make decisions. We just follow the patterns without thinking about it.
While it may be tempting to jump to program execution, it is necessary to take time in the planning phase. You must know who all of your stakeholders are, how they are connected to each other, and their degree of influence and interest in the program. Strive to understand the connections between your program and others in the organization, along with the impact on existing processes or groups. Uncover supporters and change agents who can help drive success, and understand who may cause “trouble” so you can deal with it as quickly as possible (Baugh, A., Stakeholder engagement: The game changer for program management, 2015).
Power and Influence
A power map is a visual depiction of stakeholders placed into quadrants based on a combination of their power or influence on the program and their interest level. Each of the quadrants within your power map has a separate associated communication strategy, as the type and frequency of communication with a stakeholder varies (Baugh, A., Stakeholder engagement: The game changer for program management, 2015):
- High power, high interest: In the top right quadrant are those with the highest level of interest and the highest level of influence. I refer to this quadrant as the power players. This is the group of people, you need to stay in regular contact with, and with which you should spend the most effort building and maintaining strong relationships.
- Low power, low interest: In the lower left quadrant are those with the lowest level of interest and the lowest level of influence. I refer to this quadrant as the sleepers. You may want to make information available to this group of stakeholders, but compared to others, less time should be focused on this group.
- High power, low interest: This group is found in the top left quad-rant. I refer to this quadrant as the danger zone. This quadrant is tricky, and if not handled properly these stakeholders can threaten the success of your program. This group tends not to be fully engaged in the program; they may be distracted by other competing initiatives or be spending their time and energy elsewhere, until they are more focused on your program and become positive proponents for it. Communications to this group must be handled carefully. Those in this group have high influence but only show up periodically to meetings. They tend to make assumptions and, even worse, decisions based on partial information. It is crucial to carefully think through the communications plan for this group, with an emphasis on focused communications that convey the most important information.
- Low power, high interest: This is another interesting group. For stakeholders in this group, it makes sense to give them a lot of information. I refer to this quadrant as the informants. These are often the people who think they have a lot of influence, but in actuality they do not — at least not from a decision-making standpoint. Where they are influential is in getting the word out, good or bad. These people can be champions for your program, and positive publicity is always a good thing. On the other hand, they can be critics and can therefore be a corrosive force to your program. Given this emphasis, a good strategy here is to maintain regular communication, primarily by providing a lot of information. This group can also be beneficial as they may be a means to new ideas or approaches, and while they may not directly have a high level of power, they are still a good resource use.
Influence and Trust
In order to achieve these, Strategy and Stakeholder Management must become inseparable. To that end, I found important that designers understand the co-relation of communication and relationships, and the importance building trust.
A good way to start is to understand and identify Cultural, Social, Political, and Technical issues of working with teams and stakeholders, master collaboration, and have a good grasp of what it takes to become a Trusted Advisor.
These will speak more for you than the words that come out of your mouth in a meeting. I couldn’t agree more with Greever (2020) when he says that it’s ironic that Uxers are so good at putting the user first, at garnering empathy for and attempting to see the interface from the perspective of the user. Yet, we often fail to do the same thing for the people who hold the key to our success.
The foundation of good project communications starts with building trust among your team and stakeholders. The best way to get to a place where everyone is trusted and respected is by being honest. That’s right, drop your guard and recognize that hiding mistakes, ideas that could put you over scope, awkward client conversations, or whatever else that gives you the project heebee-jeebees will never be good for the team or the project. Earn trust by simply sharing important project details and conversations in the open. At the same time, take time to form relationships with your team and stakeholders. This can be done through conversations or interactions that not only focus on the project, its goals, and how you’ll work together to meet them, but also about yourselves. (Harned, B., Project Management for Humans, 2017):
Handling Communication and Stakeholder Management
Managing the client’s design expectations is an important part of how successful a project is considered to be. As an iterative process, design encourages the integrations of new discoveries, opportunities and constraints identified during each project stage. Monitoring progress regularly, and communicating effectively with the client and the design teams, will inspire confidence in both the process and those involved with the project. During the course of a project’s lifetime, a number of circumstances will inevitably influence how closely the proposed project plan maps what is actually happening. Good project managers are flexible and yet remain objective, balanced and realistic in how they respond to the client and design challenges that arise (Best, K., Design management: Managing design strategy, process and implementation, 2019).
Good communication in project management has four characteristics (Best, K., Design management: Managing design strategy, process and implementation, 2019):
- Ensuring that all sides understand the problem and are fully briefed;
- Ensuring that all sides understand each other and are talking the same language;
- Ensuring that all sides are always fully informed, sharing problems and solutions
- Encouraging all side to share experiences and knowledge, especially on details, procedure and knowledge.
Quick Simple Communication Tactics in Project Management
Relationship building (and joke telling) aside, think about your project communications in terms of routines. As a PM, you want to be sure that you’re facilitating the flow of information in a way that feels expected. Doing so helps your team share information more easily or ask for it when it’s needed. Some basic ways to ensure there is a consistent flow of information are the following (Harned, B., Project Management for Humans, 2017):
- Establish what “success” means. When you kick off a project, you’ll want to make sure that your team and stakeholders are aware of what’s expected of them throughout the course of the project—and for you to understand what’s expected of you from the team as well. What’s most important is to get the details on the table and ask, “What does success look like for us and how might we fail on this project?” Being truly honest about what’s going to make you all feel good about the project when it’s over—from the administrative end of the project to the front-line project communications—will help you set expectations early on.
- Discuss deliverables. It’s easy to check boxes off on a plan and do that on time. But if you’re not actively checking in on those deliverables and reviewing them as a team, you’re missing a huge opportunity to collaborate as a team“and build a stronger product. When you’re building your plan, make sure that you’re working in some time for team deliverable reviews. Sit down and discuss or critique your deliverables. This will generate more confidence in what you’re building and will also hold team members accountable for project decisions throughout the course of the project, even if they’re not responsible for those items at the time. Essentially, through short review and discussion, you’re eliminating the risk that a current deliverable will have a negative impact on your scope later in the project. It’s well worth your time.
- Conduct status meetings. Status meetings (scrum, stand-ups—whatever you call them as a team) are necessary. Create a routine that will keep everyone informed about progress or blockers. Maybe you’ll meet daily as a team, or maybe it will be weekly. You should be able to make that decision as a team to ensure a good flow of information. You’ll want to do that with your stakeholders as well to ensure that they’re seeing progress and know where they fit in the process.
- Ask questions. Being a PM requires you to be inquisitive—you have to understand processes, people, and deliverables. Chances are, you’ll work with someone who comes up with a new way of working or takes a new spin on a deliverable. That’s great! Just make sure that you understand it—and that you can articulate the what, why, when, and how of that new thing. And never be afraid to ask questions. Your team will likely be happy to share information or resources about the work to help you understand it better. And in the end, it’s a win-win situation for you and your team, because the more you understand the work, the easier it is for you to advocate for it with stakeholders, or plan for similar activities in future projects.
- Schedule working sessions. Scheduling collaborative brainstorming or “whiteboarding” sessions gets project team members invested in project ideas before they become more concrete, and it helps deal with potential scope issues. Simply having a developer sit with a designer to talk through the level of effort an idea might require can be a lifesaver when it’s discussed before it goes to a client.
- Be the cheerleader. You may not be a peppy cheerleader by nature, but every project needs a leader who owns and supports the process. A good project manager will enforce the process and keep everyone on the team in sync. Juggling timelines, deadlines, and deliverables is key, but a project manager who also supports the process, the team, and the client, brings true value to a project. Be the one who says, “Wow, this is really nice. Good work.” Celebrate the wins and encourage the team to do the same.
- Play devil’s advocate. This is a tricky one—particularly because no one likes to be questioned. So, proceed with caution! But if you see something that might not be in line with project goals, or reminds you of an offhand comment from a client, raise it. Maybe you’d say something like, “Did you think about X?” and explain why you’re thinking it. At the end of the day, you must look out for the best interests of the project and your team. This type of behavior not only supports your team and your project, but also shows everyone involved that you are genuinely engaged and not just worried about the PM basics.
- Informal check-ins. Between deadlines, check in on the upcoming document or delivery and chat with the team about what each will entail. Are your deliverables changing based on previous work? Will that impact the scope and the timeline? Explain the benefits of check-ins and how their constructive, helpful feedback will make the end deliverable stronger. Remember when it comes to setting expectations, there is nothing wrong with repeating yourself as long as your repetition is meaningful and timed just right
Just Enough Planning in Project Management
As I mentioned in the beginning: that – while Strategists are not expected to fully manage design projects in their area of responsibility – there are some Project Management skills that will prove invaluable for their effectiveness.
I’ve also mentioned in several posts that I believe designers should step up to the plate and work with stakeholders to facilitate the discussions that will better communicate the vision (or create one is it is lacking) and get teams paddling on the same direction.
At this point you might be thinking and asking yourself:
- Isn’t it Someone Else’s job? I’ve had people suggest that a product manager, or a product owner, or a someone in some business capacity should be ensuring the team has a clear vision and goals. That’s probably right! And yet, what I’ve noticed in my practice is that most of the decisions we’ve been talking about here are related to key questions you as a designer would need answers to do your own work: what are the personas we are trying to help? what are their key problems? What do they consider success? From that perspective, I found it more helpful to frame the facilitation discussion as “if we can’t answer these questions as a team, shall we get together and work them through?” Once framed this way, it’s usually the case that teams will not only welcome the facilitation exercise, but also ask for more in the future!
- Even if I had all the skills and mindset above, how am I going to lead the team through these discussions? That involves a few key soft skills, particularly influencing without authority.
The grasp of such important concept is what differentiates people with delegated authority and earned authority: if you had to ask for the team to “let you lead them” through some amount of project management, you will probably find some stakeholder to support you (your manager, a scrum master, or a sympathetic product manager). That approach might work depending on how successful you are in finding (and collaborating with) such stakeholder.
The best way to start is (in my opinion) with a two-pronged approach:
- Find an area you can influence that could benefit from some structure (remember: “the more freedom you have, the more structure you will need”). If nothing else, design strategists should project management their area of responsibility (e.g.: research and concept, design thinking, etc.) and lead by example.
- Instead of going from no-project-management-capability to a six-sigma-black-belt-certification, find a balance of just enough planning to begin with.
There are seven straight-forward practices that — if followed in the planning process — increase the probability of successful strategic plan development and execution (Dobbs, J. H., & Dobbs, J. F., Strategic Planning: A Pragmatic Guide, 2016):
- Start with a practical, pragmatic approach to planning, rather than an academic, theoretical one.
- Follow a clearly defined, sequential planning model that is decided on in advance and accepted by participants.
- Ask and answer necessary and sufficient questions at the right times and at each stage in the planning process.
- Use objective criteria for decision making
- Create alignment among stakeholders around key facts, assumptions, and decisions.
- Commit to and manage a reasonable portfolio of strategic actions or initiatives.
- Acknowledge reality in order to foster self-honesty.
Design Strategist Multiplication Program
As I mentioned in the beginning of a previous post, myself and my colleague Edmund Azigi are designing a Design Strategist Multiplier program per request of Scott Lietzke, our VP of Design at SAP SuccessFactors.
In order for this kind of profession development program to work — in my opinion — should be practice-based, accompanied with a series of seminars, corresponding required reading and reflective practice journaling to create the opportunities for people to grow.
This post was the last of a series in which I’ve went through the skills of a strategist (namely: thought leadership, stakeholder analysis and management, facilitating decision making and project management) and challenging you with questions that will help you think of ways to how to pick up these skills yourself.
Anderson, G. (2019). Mastering Collaboration: Make Working Together Less Painful and More Productive. O’Reilly UK Ltd.
Benson, B., (2019), Why Are We Yelling?: The Art of Productive Disagreement. Portfolio; Illustrated Edition.
Berger, W. (2019). The book of beautiful questions: The powerful questions that will help you decide, create, connect, and lead. New York, NY: Bloomsbury Publishing.
Best, K. (2019). Design management: Managing design strategy, process and implementation. London, England: Bloomsbury Visual Arts.
Berkun, S. (2008). Making things happen: Mastering project management. Sebastopol, CA: O’Reilly Media.
Brown, T., & Katz, B. (2009). Change by design: how design thinking transforms organizations and inspires innovation. [New York]: Harper Business.
Bucher, A. (2020). Engaged: Designing for Behavior Change, Rosenfeld Media; 1st edition (March 3, 2020)
Calabretta, G., Gemser G., Karpen, I., (2016) “Strategic Design: 8 Essential Practices Every Strategic Designer Must Master“, 240 pages, BIS Publishers; 1st edition (22 Nov. 2016)
Callahan, S. (2016). Putting Stories to Work: Mastering Business Storytelling. Melbourne, Australia: Pepperberg Press (18 Mar. 2016).
Détienne, F. (2006). Collaborative design: Managing task interdependencies and multiple perspectives. Interacting with Computers (18), 1–20
Dobbs, J. H., & Dobbs, J. F. (2016). Strategic Planning: A Pragmatic Guide. Independently published.
Fisher, R., & Ury, W. (2012). Getting to Yes: Negotiating an agreement without giving in (3rd ed.). London, England: Random House Business Books.
Garrett, J., (2010), “The Elements of User Experience: User-Centered Design for the Web and Beyond“, 192 pages, New Riders; 2nd edition (16 Dec. 2010).
Gothelf, J., & Seiden, J. (2021). Lean UX: Applying lean principles to improve user experience, 3rd edition. Sebastopol, CA: O’Reilly Media.
Gray, D., Brown, S., & Macanufo, J. (2010). Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Sebastopol, CA: O’Reilly Media.
Greever, T. (2020). Articulating Design Decisions (2nd edition). Sebastopol, CA: O’Reilly Media.
Hammond, J. S., Keeney, R. L., & Raiffa, H. (2015). Smart choices: A practical guide to making better decisions. Boston, MA: Harvard Business Review Press.
Harned, B. (2017). Project Management for Humans: Helping People Get Things Done (1st edition). Brooklyn, New York USA: Rosenfeld Media.
Hoffman, K. M. (2018). Meeting Design: For Managers, Makers, and Everyone. Two Waves Books.
Justice, T., & Jamieson, D. (2012). The Facilitator’s Fieldbook (3rd ed.). Amacom.
Kindersley, D. (2010). The Book of Management. Great Britain: DK.
King, P. (2019). The Art of Clear Thinking: Mental models for better reasoning, judgment, analysis, and learning. Upgrade your intellectual toolkit. Pkcs Media.
Lencioni, P. M. (2011). Overcoming the five dysfunctions of a team: A field guide for leaders, managers, and facilitators (J. Leffert, Trans.). Recorded Books.
Martin, R. (2014). The big lie of strategic planning. Harvard Business Review, 92(1–2).
Maxwell, J. C. (2007). The 21 irrefutable laws of leadership: Follow them and people will follow you. Nashville, TN: Thomas Nelson.
Maxwell, J. C. (2013). The 17 indisputable laws of teamwork: Embrace them and empower your team. Nashville, TN: Thomas Nelson.
Maister, D. H., Galford, R., & Green, C. (2021). The trusted advisor: 20th Anniversary Edition, New York, NY: Simon & Schuster.
Ouertani, M. (2008). Supporting conflict management in collaborative design: An approach to assess engineering change impacts. Computers in Industry (59), 882–893.
Perri, M. (2019). Escaping the build trap. Sebastopol, CA: O’Reilly Media.
Podeswa, H. (2021). The Agile Guide to Business Analysis and Planning: From Strategic Plan to Continuous Value Delivery. Boston, MA: Addison Wesley.
Project Management Institute. (2017). A guide to the project management body of knowledge (PMBOK guide) (Sixth Edition). Newtown Square, PA (USA): Project Management Institute.
Project Management Institute. (2017). Agile practice guide. Newton Square, PA: Project Management Institute.
Ramroth, W. (2006). Project Management for Design Professionals. Chicago, IL: Kaplan Business.
Riel, J., & Martin, R. L. (2017). Creating great choices: A leader’s guide to integrative thinking. Boston, MA: Harvard Business Review Press.
Seiden, J. (2019). Outcomes Over Output: Why customer behavior is the key metric for business success. Independently published (April 8, 2019).
Smutny, M. (2019). Thrive: The Facilitator’s Guide to Radically Inclusive Meetings. Bothell, WA: Civic Reinventions, Inc. (August 10, 2019).
Stickdorn, M., Hormess, M. E., Lawrence, A., & Schneider, J. (2018). This is Service Design Doing. Sebastopol, CA: O’Reilly Media.
Thaler, R. H., & Sunstein, C. R. (2009). Nudge: Improving decisions about health, wealth and happiness. New York, NY: Penguin.
Torres, T. (2021). Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value. Product Talk LLC.
Udo, N. & Koppensteiner, S. (2004). What are the core competencies of a successful project manager? Paper presented at PMI® Global Congress 2004—EMEA, Prague, Czech Republic. Newtown Square, PA: Project Management Institute. Retrieved from https://www.pmi.org/learning/library/core-competencies-successful-skill-manager-8426
Wikipedia contributors. (2021, September 18). Tower of Babel. Retrieved October 13, 2021, from Wikipedia, The Free Encyclopedia website: https://en.wikipedia.org/w/index.php?title=Tower_of_Babel&oldid=1044983998
Zook, C., & Allen, J. (2012). Repeatability: build enduring businesses for a world of constant change. Boston, Mass.: Harvard Business Review Press