Project Management for Design Leads
Having just finished work on my latest project at IBM, we’ve been doing wrap-up retrospectives and lessons learned. A particular area of change for me has been project management. It’s something I didn’t have a lot of skills in when I started as a designer, and an area I have had to get better at. So I thought I’d share lessons learned on that topic here and some of my plans to do more.
I’ve read two articles which have stuck with me recently. One is the excellent Effective Technical Leadership by David Byttow. David looks at leadership from a development perspective, but many of the points he makes are widely applicable. What do teams need from leads in technical positions such as Development or Design? As a lead, what responsibilities do I have over and above those of a regular developer or designer?
The other article I think is highly relevant is Let’s Stop Doing Research* by Erika Hall. Erika is looking specifically at the topic of effective research practices, but a broader point she makes throughout is the need for an effective environment to do good design. Designers need to be great designers, but they also need to create environments where great design can be done. We have to be able to build a foundation framework and alignment for research and design to build on.
The challenges
I don’t believe project management as a designer is fundamentally different to project management in other roles. Nonetheless, it’s worth looking at from the point of view of designers, to bring the lessons to the forefront.
1. Tracking & prioritisation
Modern product design involves a large swathe of work at many levels of fidelity. There’s multiple releases, the various features, the different categories of users, the early concepts, the prototypes, the style guides, the client presentations, the research activities. It’s critical to be able to track all the work that is going on, all the work to do, and how it relates to what actually ships. As a design lead I need to track the details of our research activities. As a development stakeholder though you only need to know where design is with their work for the current milestone/iteration etc. So there are the dual aspects of internally tracking detailed work for your design team, and externally tracking your progress against project goals.
There’s also the question of prioritisation. If new work is identified, could it be done next week? What would the impact be on other work? In order to answer these kinds of requests, (and not be constantly firefighting), you need a clear sense of what work you have, how much time it will take, and why you’re doing it. Without that clarity you just get more work on top of an amorphous pile. Too much work in flight has a huge impact on productivity because you’re trying to multitask too many things. It also creates risk because if there is a future pivot, you have more work impacted. Good tracking makes prioritisation easier and makes you more productive by keeping work in flight to a minimum.
2. Engagement & Validation
Good project management is also important in order to get the right kind of input from the right people at the right time. For a given piece of work you need to bring in the right people to make good decisions. Particularly in an area like UX design which involves such a holistic view, there are a lot of perspectives to involve. How do you ensure everybody who matters is involved in any ongoing work, and prevent having to revisit decisions later?
The right time is important in order to keep the team unblocked and making progress, and to prevent revisiting earlier decisions because somebody wasn’t engaged, (or didn’t involve themselves,) at the appropriate point.
The right people means involving stakeholders, customers or users at the right point to validate you’re designing for the right problem. It also means that you’re bringing in technical specialists to explore constraints with you at a time when you have a clear enough idea of what you’re trying to do, without yet having wasted time designing unaware of constraints.
The right kind of input means not just getting people’s opinions on the project, but focusing on the kind of input which is relevant. Anybody who has shown a Balsamiq wireframe and been told the font isn’t good knows the problem. The solution is to constrain the type of input you ask for, and clearly define it for your stakeholders. That means everybody needs a clear sense of what part of the process you’re in and what the scope of the task is. Not just “we’re working on this feature”, but “we’re looking at strengths and weaknesses of this early mobile concept for our Free user”.
So these are some of the challenges I see in design teams, and some areas which I think good project management should be able to help.
- Tracking work (both for yourself and others)
- Prioritisation with stakeholders
- Engaging others reliably and with purpose
- Validating choices quickly and consistently
What were we doing that wasn’t working?
Coming into my most recent project my techniques for project management were (in hindsight) pretty woeful. We would keep a list of work to do in a wiki. We would assign that to individuals, and if anybody asked what was going on I’d point people at a wiki page.
It was usually up to date, sort of. It was lacking a lot of detail because it was just a spreadsheet. Usually the actual work was elsewhere and people who needed more detail would go find that. It gave a high level sense of what we were working on, but not day to day detail or specifics of the kinds of engagement which would be beneficial.
It worked in the sense that we weren’t sitting on our hands doing nothing, but there was a lot to improve:
- It didn’t provide a good way of keeping our tracking up to date.
- It was hard to communicate the association between design work and project objectives.
- It was vague making it hard to engage stakeholders at the right times for feedback.
- Stakeholders waited for us to mark things complete before bothering to validate except for when we explicitly booked time with them.
- There was no serendipity — we’d only get the feedback we asked for, not any deeper engagement because it was hard for others to do so
What does a better model look like?
A fundamental improvement we’ve put in place as a Design team over the course of the last project cycle has been to be far more transparent about our work in flight. That was always the goal, we were already doing sprints, and milestones, and roadmaps, but we hadn’t found a way of doing it which didn’t add a tremendous amount of work. On our latest project we’ve moved our planning and tracking to a combination of Github + Zenhub. For us it has proved to be the right mix of lightweight and open. The result is we track far more, and far more precisely, than before.
Github is a development tool used for storing code and managing work items (issues). Zenhub is a plugin to Github which displays your work items in series of columns which you can move work between to track progress. I know many teams Design teams already use Git + Zenhub, or similar tools, in collaboration with their development team. What I’d advocate is that even if your development team doesn’t store their code in Github, consider it anyway just for project management.
We use Github to track our entire backlog of work, from the larger feature items, down to the smaller to-dos. Because it’s very simple to create an issue we’re much better at tracking work than we were in the past. As a result we’re tracking all the diverse work we do as a design team from building visual systems, to prototyping on paper, to research activities. It changes daily rather than occasionally.
We have a sprint set up for every week and work assigned to them. That means we know as a team what we completed last week, what we’re doing this week, and the priorities for the next. Other stakeholders can see exactly the same. If work is missing they can open issues for it, and we can triage them.
We size issues in Git so that we have a general sense of how much work we have committed. Not by how many hours it will take, but a relative sizing using story points. In other words, “is this piece of work bigger or smaller than this other piece”. Rather than stakeholders telling us how long it ought to take us to complete some work, I can refer to similar work of the same size. I can see that we completed 72 points of work last week, and that we have 61 points committed next week. That’s an indication that we can either pickup more work from the backlog, or if last minute requests come in from stakeholders, we can probably fit them in. If I can’t fit them in, I can give a clear picture of why, and we can have a very straightforward discussion about which work is higher priority.
We have clear assignments, literally passing issues back and forth between people as the work progresses. It’s obvious to all who the designer is currently progressing some work. They can link the sketch files, or provide screenshots in the issues directly to show progress. We can filter on what open work there is, how many remaining interviews we have to conduct before the research portion is closed. I can easily find all the open visual design tasks.
We can directly engage other stakeholders by @ including them in comments to have very specific conversations. They in turn can relate work they’re doing to work we’re doing. Code or development tasks can be associated with design tasks to help make it clear who’s working on what, and to stay in touch with progress. Interested in an issue? Subscribe to it. Designers are no longer responsible for knowing which stakeholders care about an issue, they can follow themselves.
Starting to change
The key with any kind of project retrospective is to find out what is working for you and what isn’t. Not to wholly implement a different process. For example, Spotify have some great videos for how their product teams work, but if you think “success” means copying them I think you’ll be doomed to failure. So much of what their team does is optimisation based on what they were doing the month before. They are A/B testing their way to a better project model. Optimising your model might look very different.
The right process for your team depends on your project’s level of maturity. Your project has to grow up, not just copy the behaviour of adults. My team is in the equivalent of its teenage years. We’re somebody’s older brother, and somebody else's naive child. So if your project management is an issue, or you’re seeing the symptoms of poor project management, and you’re not sure where to start, maybe my example can indicate one or two useful steps.
I see so many design teams who aren’t managing themselves well, or are reliant on their product team’s existing management model. They aren’t having to really think about what is and isn’t working. They run smoothly whilst the project runs smoothly, but when there is churn the design team go off the rails along with everybody else. Particularly today whilst Design and UX is in such a formative period with respect to product design, there are so many design teams trying to implement major culture change. I think we’re better able to create the environment for successful design if we understand methods like this for effectively running projects, if we can take the lead in key areas beyond the actual craft of design. If your project is running smoothly, do you know why? If it is not, do you know what you can do to improve it?
If your timelines are getting squeezed by stakeholders who think something should “only take a couple of hours”. If you’re being told there is no time for research. If you’re constantly being asked to fit extra work in and having to cut corners, take a look at how you are managing your own work. Models like this can help you have a much clearer conversation about what commitments you already have, how much work they are, and what your work looks like for future sprints. That doesn’t mean you’ll never have to do more work than you want to, but it means you are negotiating about what work is most important rather than just “fitting it in”. The impact of new work becomes much more obvious to all.
If you understand the value, then hopefully my specific example of using these tools to manage our work items gives you some pointers for doing something similar.
Ideas for the next improvement
At the moment the work we are tracking is relatively flat. That is to say it’s a list of to-dos, occasionally associated with each other by links and comments, but primarily just a large list of tasks. It’s also spread across several different repositories because, for various reasons related to project scale, we have several repos (Design, UI, Backend, prototypes etc). So it’s up to the project team to keep a clear picture in their head of how the tasks relate to stories, relate to customer value. We often try to write user story style issues (“As user ___ I can ____ so that___”), but they are quickly overwhelmed by the number of small work items associated with implementing them.
Very timely for me, Zenhub have recently released an update including Epic planning which allows creation of higher level tasks (Epics) which we then fill with individual issues from multiple different repos. So my plan for next milestone is to work with our product management team to better tie our high level epics into our finer grained planning process. The intent is to use those epics we already have as clearly labelled containers for Design activities, Development work items, Copy and Marketing items, Legal etc. That way we can track not just the tasks, but overall product features breakdown into an accumulation of tasks we’re currently progressing. I hope that will substantially improve our ability to track tasks across disciplines, and to estimate remaining project work to implement an epic.
How do you clarify your project goals to get clearly defined epics? Take a look at my previous article on combining Design Thinking and Agile in Practice. In that article I covered a workshop looking at how to use Design Thinking to build a user experience driven project idea, and generate a list of critical epics needed to deliver an MVP. Those epics are exactly what you would want to use here to start tracking your individual design tasks.
