Natalie Hanson Just say no
Last year, the User Experience team that I manage at SAP really started to make a name for itself. We were involved in multiple transformation projects sponsored by the Chief Operating Officer (COO), and we began to establish relationships with several executive stakeholders who advocated for our deeper involvement in those projects. I wrote about that tipping point in January of last year. It was a long awaited, beautiful thing!
In those projects, User Experience services were considered and embedded early in the project planning, which ensured that we weren’t in fire-drill mode. We had a chance to assess which UX services made the most sense, align those recommendations with key stakeholders, and get the project properly planned and staffed. But with all of the organizational changes underway at SAP (you can read about them here, here, and here), some of that planning and alignment has been disrupted this year, and it’s not as clear to me what the right priorities are, what level of resource investment we should make in which projects, and so on.
So, as we began scoping a new wave of strategic projects this year, I am trying to build relationships with new stakeholders, and working to deepen our relationship with existing ones. For people that are interested but don’t know much about User Experience, I’ve been looking for new ways to explain how we should be engaged, and how the organization benefits from proactive involvement of UX in project planning and scoping.
SAP IT’s project management framework (Plan-Build-Run), is high level enough to be understood even by those that are not familiar with the underlying details, so I built this slide to show how the major types of UX work (e.g. Research and Design) overlay a classic project management approach. The body of the slide describes the value proposition of UX services by phase, the bottom part of the slide is a series of thumbnails that depict deliverables from some of our projects. I use the thumbnails as reference points to provide examples from prior projects, based on what I think my client is trying to accomplish.
I have found this slide and talk track to be a great help in messaging the importance of our early involvement in projects. But as I thought back to the projects we’ve been engaged in since I started the team in 2005, I realized how many project sponsors and managers sought us out when they were well into Build, thinking, “Oh, I think we have some usability issues here, let’s get UX engaged!” It all seems really obvious, but in retrospect I’m realizing that our early involvement in projects has happened a lot less often than I would care to admit.
In order to support as many projects as possible, in the past we found ourselves doing a lot of Expert Reviews, which bring together a user researcher and a designer to evaluate a system and provide some high level guidance on how it could be improved based on industry best practices for usability and design. While Expert Reviews are an important aspect of our User Experience service offerings, I have concerns about them, too:
- The Expert Review doesn’t involve end-users in any way, except for the fact that we take our pre-existing knowledge of a user population into consideration when conduct the evaluation and make recommendations.
- While these shorter engagements help the UX team gain exposure to a wide variety of internal systems and processes, the service sometimes rewards bad behavior. That is, requestors come to us late and without knowledge of or access to the end-users of their proposed solution, and they still get UX support.
- It’s often the case that we’re telling the requestor what’s wrong with their solution just before go-live, and they are not actually able to make any of the changes we recommend. We work with them to assess urgency, and help them determine which of our recommendations they’ll address in a subsequent release, but there oftentimes very little immediate business impact.
And the reality is that, even if we do some Expert Reviews this year, our pipeline of project work is much greater than our capacity, so I am going to have to say no to some work. Based on what we’ve learned, we’re going to say ‘yes’ to people that come and talk to us here:
And to most of these, we’re going to just say no:
I believe that this approach gives us a better chance of having strong, closed-loop success stories to sell future services. However, we’ve rarely turned down work before, so this represents a new (and sometimes uncomfortable) place in our maturity and growth as a UX organization. It should be interesting to see how it goes this year, and to see if we do improve our ability to deliver those success stories as a result!
Natalie Hanson 
Pingback: 2010 in review « Natalie Hanson, PhD
Pingback: On being busy | Natalie Hanson, PhD
Pingback: On being busy | Natalie Hanson