Designing for Collective Accountability
There is one situation that all designers, at least this designer, loves and fears at the same time–working for another designer.
Themes: Internal Service Design, Operations, Project Management, Process and Collaboration
Goals:
Scoping
The assignment was to develop a template for design projects. The client was a design firm of 35 people, and would have small teams of 2 to 5 people work projects, but there was no consistent process moving from business lead to contract through completion. A template would allow there to be a unified checklist, making sure a few tasks were always completed, no matter what the project, and it could also be a working document that the teams used to move towards completion. The first step in one of my organizational projects, after all of the contracts are signed, is scoping the project. This project was not only a complex beast of information, procedure, and people, but it also existed in a larger context, the design firm itself and branched off into HR, Sales, and Management.
My main contact for this project, let’s call him John, walked me through what he thought I should do and who I should interview to get a better sense of the problem. John explained that the design firm was split into Business People, User Centered People, and Graphics People. The Business People brought in the work, they wrote up the contracts, they had meetings with clients. Then the User Centered People put the most hours into the actual projects, which were 3 months to several years. And that whole time, the Graphics People were there helping to document every step of the process. John figured that it would be helpful if someone looked at all the steps of that process, from finding a client, to negotiating, to creating a project with a budget and milestones and due dates, and then creating a template that the Business People could follow. Being an outsider with a three month contract, it seemed like a job for someone else, but I had the full support of John and a couple other high level folks, so I started a bit of research.
Tommy
Tommy is the youngest of the Business People. I was probably pointed in his direction because he was low on the totem pole and noboby wanted to take billable hours away from top people. Tommy walked me through the typical project. Someone in the design firm knows someone in another company. They get to talking, and at some point realize that it might be a good idea to work together. The sales guy at the design firm starts tracking progress with this company. He starts figuring out if the project is the right size, if the design firm has the resources for it, if the firm has the skills. At some point a proposal is written up, usually by a Business Person that loosely outlines a bit of work. Then there’s a meeting with the other company’s management team and one of the Business People in the design firm where more details of the project are fleshed out. Another project proposal is written up with more detail, some User Centered People and some Graphics People get assigned to the project, and the Business Person manages the client and the team throughout the project.
At this point, I felt like I had a rough sketch of the process, and wanted to learn more about the information systems that were used to track all these moving parts. The Sales Guy had a hardcore excel setup to track sales progress and expected revenue per month. Each project had a row in the spreedsheet, and each column had an amount for a month in the future. This way, the design firm could estimate how much revenue it would have per month based on project estimates. So if a project was 100,000 dollars split over 10 months, each month would be 10,000 of revenue, but there was also a probability rating to determine if the project would actually happen based on signatures and past experience with the client, and that probability rating would be multiplied by the revenue. This was a forcasting device to help the company plan. Everyone in the company with billable hours used an online tool for tracking how much work they did for each project. So there as one system for forcasting, and one system for keeping track of the present state.
Tommy thought that if there was a project proposal template, with check boxes, that would go a long way. There already seemed to be a fair amount of tracking, but not much planning. He thought this could be a living document that would move with the project, and even suggest weekly meetings between the Business Person and the rest of the project team. A checkbox could be something like “Did you check with the head of the graphics team to make sure they have the resources to take on this project?” or “Schedule a weekly meeting with the User Centered People who are a part of the project to check on their hours and milestones”.
Sarah
Sarah was the head of the Graphic Designers. Apparently each group (Business People, User Centered People, and Graphics People) had a head, but it seemed like in some groups, this was just a sign of seniority and didn’t come with any power, just more non-billable hours and more pay. Sarah wasn’t like that though. Everyone in her group looked to her for mentorship, and she single handedly assigned designers to different projects based on experience, interest, and aptitude for learning. Sarah seemed frustarted with the way projects were run at the Design Firm.
Graphic design was an after thought. Instead of being a part of the conversation with Business People when putting together a project proposal, Sarah seemed to be relegated to putting out aesthetic fires, and could never take the time to properly plan out how people on her team were delegated to projects. If the Business People consulted her on a project while writing up the proposal, she would have a better understanding of the type of work, the amount of work, and who on her team would be most suited for the job. The Business People had no idea how much time it took to create a beautiful final report, and continually under estimated the level of effort for graphic design work. Of course this attributed to projects going over budget.
I asked Sarah why she didn’t look at the excel document with revenue projections for each project coming down the line, and I infered from her attitude, it was either wrong for her to look at the numbers of the business, some cultural standard, or she didn’t understand how to read the document, or possibly that she felt she was too busy putting out fires. By this time, I started having a good idea of the timeline of projects and a few pain points within the process. It seemed like having a project template would not only codify a process, but it would also make sure the right people were involved. Instead of thinking of the document as just a list of tasks, it could be thought of as a tool to bring siloed groups of people together–a document that is for discussion and not individual use. I was getting excited, a possible solution was forming, but I still had no idea if that was the right direction.
And then, Sarah told me something that blew my mind. “Oh yeah, we made one of those a year ago”. She said it so matter of factly, that it took me aback. She went on to pull up some massive documents showing the stages of projects, listing groups of stakeholders to be included. The project template even suggested a weekly meeting between the design team and the Business Person, which I thought was a great idea. “Me and Frank and Tommy all spent about 3 months working on this system.” Tommy was a business guy that I had already talked to who didn’t even mention this, and Frank was a member of the user research team, and now that Sarah had run out of time, Frank was next on my list of interviewees.
Frank
“You see all those people who have their own laptops? Well they all came into the company when it was just a bunch of independent contractors.” Frank was giving me the history of the company. It confused me to think of 3 people in a company spending 3 months on a project template that nobody used. Why wasn’t it used? Who authorized it just to let it die after hundreds of hours had been poured into it. Frank was explaining that most of the older guys (and I do mean guys, as there were zero women), most of the people in the business group, used to be independent contractors and really just want to do billable work and be left alone. Frank explained that since the organization was completely flat, it was hard to get people to do anything. He mentioned that there had been several attempts to get everyone on the same page in project planning, and even attempts at codifying proposals that went out to prospective clients had been dismissed. It seemed like older people had power just because they were older, and since there really weren’t any promotions or job titles built into a hierarchy, it was hard to displace that cultural power.
Cranking
So there I was, at the bottom of the totem pole of power, with three weeks left in my contract, assigned to get everyone in the org to work projects a little better. I knew that there was a problem at the onset of projects, when a project was formed the right people were not at the table, and I knew that because of that poor planning, projects were burning faster than they should, and because no one was checking on projects, things could get really bad before anyone noticed. The hardest part for me at the time was figuring out what the final product was going to be. If you’re hired to make a website, or a chair, or a planned event you know that going in. I was brought in to make a project template of sorts, but after many conversations, and armed with the evidence that this approach had been taken before and didn’t work out so well, I was given some flex on what kind of widget to design.
Since there seemed to be a strong culture that pushed aside attempts at structural overhead or structural anything, I decided to take advantage of this. Instead of creating something and trying to get people to follow it, I could create something that would push everyone in the org to be more open about their project process and progress. There was a system that projected the revenue of the firm, and there was a system that recorded hours. I ended up hacking together a system that combined the two. If a project was supposed to burn through 100k in four months, and after 2 months, the project had burned through 60k, then the project was burning too fast. The Business Person managing the project should know about this, the design team should adjust their hours, and the rest of the organization should try to help out in any way it could.
This concept of creating openess lead to a visual interface that showed projected cost of each project, where the project should be (in this case, around 50k) and where the project currently was (in this case, 60k) in a place that couldn’t be avoided… the kitchen. Everyone went into the kitchen multiple times a day. It was a place for informal conversation and socializing. The concept was that if everyone in the organization new that Tommy (for example) had a project that was 10k over-spent, Tommy would work hard to fix that, and that the organization would do a better job of self regulation through instant feedback. I considered the project a success in a single moment. After three weeks of HTTP Requests and Perl code (yes, I actually coded it, and yes in Perl), I walked over to the CFO’s office and showed her a chart of every single project currently going on. She asked one question “Why is that one red?”, I answered, she set a meeting.