Our team had a set of defining characteristics and was almost ready to start redesigning cloudfour.com. But before we dived into element collages (more on that in a future post), we wanted to draw from a shared well of design inspiration. So we decided to make a mood board.
A mood board is a collage of reference imagery from the outside world with some relevance to the project in question. It can include examples of typography, colors, illustrations, photography or other stylistic elements. Traditionally, you’d assemble one from magazine clippings or whatever else you didn’t mind cutting up and gluing to foam core.
We decided against the cut-and-paste method for a couple of reasons:
- Most of the team’s favorite sources of inspiration are easier to assemble digitally than in physical form. One could argue that the value of a mood board exercise is in exploring sources outside one’s typical frame of reference, but for this project it felt like a poor fit.
- By this point, our team was engaged in parallel projects that made scheduling a day-long, in-person exercise difficult to coordinate.
Digital mood boards are nothing new, and there are plenty of tools to choose from (InVision’s being particularly impressive). We decided to use Pinterest, simply because most of our team was already using it.
Over the next few days, we assembled 79 pins into the cloudfour.com mood board:
Although our team members contributed independently, the overall tone of the board is fairly cohesive (possibly owing to our earlier characteristics exercise). This gave us the inspirational mind-meld we needed for the next design phase.
When we started redesigning cloudfour.com, I knew I wanted the entire team to feel a sense of ownership in the end result. To establish an inclusive design direction without designing a camel, we had to distill the collective input of every team member into one guiding vision… a singular “us.”
Fortunately for us, few problems in the universe cannot be solved by getting in a room and writing things on sticky notes.
After broadly discussing our hopes and dreams for the redesign, we jotted down words on stickies that described how we wanted Cloud Four to feel.
Each of us presented and clustered these notes on the whiteboard, grouping those that seemed thematically related.
Then, we agreed on informal titles for each cluster. These became (in no particular order):
- Web ❤
We managed to swiftly condense 93 sticky notes from nine team members into twelve tidy descriptors. I call that a successful exercise!
These directly informed our mood boards… but that’s a story for another post!
This past week, I had the luxury of attending the Digital Project Management conference in Austin. If you are a project manager and you haven’t heard about this group of awesome digital PMs, you are missing out. The first time I attended one of their events, I thought, finally! These are my people! People who actually do what I do at Cloud Four. My tribe.
What do I do, every day? What do digital project managers actually do? It’s mundane stuff, folks. In any given day, I write a ton of emails and Basecamp threads, review lists — many, many lists, in many different forms. I pester people in every way imaginable. (Letters. I’ve written actual letters at times.) I listen, a lot. I run conference calls, I Skype, I Hangout, I Slack, I SIP into meetings. Today, I slacked, then hangout, then called the same person in a 10 minute period. This is not glorious work.
It occurs to me frequently that this is work that really anyone could do. In fact, the tools we use are often designed so that anyone on my team is empowered to use them.
Want to schedule a meeting? Great! Lucid Meetings makes this really simple. It even walks you through agenda creation and attendee selection! (You know you need an agenda for every meeting, right? Make them good ones, too.) Want to ask the client a question? Perfect! Hit them up in Slack, or Basecamp. You don’t need me.
Sometimes it feels like the work we do is complete BS.
This is not the most encouraging thought to be having about your chosen career.
But here’s the thing: the reason we have project managers at all is because most people are not thinking about these things. Your project team is so heads down on the work they are doing that they don’t think about the overall project progress, or the political implications of asking a certain question, or just the right way to deal with that nagging change request. They don’t worry about the overall budget impact of that bug that was just found in QA, or how the hell you are going to schedule one extra sprint when you’ve got two other projects starting that same week.
They just don’t. But YOU do. And YOU are really freaking good at it.
[cue the inspirational music]
YOU wake up in the middle of the night, wondering why that one stakeholder didn’t seem engaged in your kick-off meeting that day.
YOU can’t shake that feeling that something isn’t right about that call you just had with your developer. She didn’t really say anything, but you know something is off and how to suss it out.
YOU know exactly how to load your project teams to maximize efficiency without overloading them.
YOU can evaluate a budget overage, report it to the customer, and offer alternatives that are actionable and clear.
YOU inspire and motivate your team to keep on keeping on.
YOU see patterns of inefficiencies in your organization and have ideas on how to address them.
And this is not just about making sure that someone (anyone) is tasked with these types of things. It’s making sure the right person is leading it.
This stuff is our DNA. And it’s not mundane or ordinary. It’s essential, technical, precise, and difficult work. It’s hard and soft skills. It’s invisible, yes, but like my ever-so-talented colleague Tyler Sticka described it, we’re like the project’s nervous system. The developers, designers, and other project team members are like arms and the legs, moving the body around, but they’d be paralyzed without a good PM to make sure signals are going where they need to be.
Like Nancy Lyons said in the closing DPM keynote, “We are change-makers, we are thinkers, we are do-ers.”
That’s some really cool, important BS, if you ask me.
What process do you use for your projects? Agile? Waterfall? Scrum? Extreme? A little bit of everything?
Join the club.
I had the pleasure of spending some time Saturday with a number of talented colleagues at the Digital PM Workshop here in Portland. I learned a lot and met some really great digital project managers.
As you might expect from a group of project managers, we talked a lot about process. When asked how participants typically run a project, I heard responses like, “Well, we’re sort of agile” or “I like to call our process broken agile” or “we’re not Agile with a capital A”. I heard a lot of qualifications and uncertainty about whether their particular method was correct.
I know the feeling. When I started at Cloud Four almost five years ago, we worked on projects with a very typical waterfall approach. In the past few years, we’ve started experimenting with ways to make our process more agile, to help address the reality that we often don’t know everything at the onset of a project, the only project constant is change, and that responsive projects tend to really benefit from rapid iterations. We started by breaking down the defined work into sprints, transitioning our clients to a more iterative process.
It’s been a fun challenge. In an agency setting, we’re grappling with integrating existing, disparate customer processes with our own, and we’re often working with ever-changing client teams. Process education becomes a burden the client must bear. Also, our customers generally want a high degree of certainty in budget and timeline when they embark upon a project with an agency.
What we’ve ended up with is something Agile-y. Agile-ish. Sort of, kind of Agile. Not agile-with-a-capital-A Agile, but you know, mostly Agile. Sometimes more waterfall-y than Agile, depending on the project and customer.
After exploring this with other web development folks, I’m pretty confident we’re all doing this. We tailor our process for the project and client that we have in hand. This is the right thing to do. One-size does not fit all when it comes to web development.
Let it go, let it go!
It’s time we let go of our process guilt that is plaguing us. There is no gold star for achieving a 100% agile process. We’re grasping for something that feels unattainable, yet it may not exist at all.
Even Dave Thomas, one of the contributors to the original Agile manifesto, has proclaimed that Agile is Dead. He pushes us to work towards developing with agility instead. Your project isn’t agile – your project exhibits agility. Your team works in an agile way. No more Agile perfectionism.
So, let go of the guilt. Own your process. Is it working for your client and your project? Are you meeting your goals? Great. If not, tweak it. Try something new. Find a process that works. Repeat it, test it, refine it.
In our case, that means we try to exhibit agility in our projects because it reduces risk and addresses the reality of the software world in which we work. That manifests itself differently for each project. Is it perfect? No. Is it agile? Yes. I’m done qualifying that statement.
GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).
Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.
We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.
It’s a complicated relationship.
Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.
Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.
We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.
In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!