flights

Please indulge a moment of self-pity…

I know a designer’s job isn’t rocket science, but that doesn’t mean everyone is qualified to make design decisions. Unfortunately for me, that doesn’t ever seem to stop people.

I can barely remember now, but before the age of MapQuest (and, subsequently, Google Maps), if I needed to go somewhere I’d never been to before, I rarely planned my route. If, for example, I wanted to go to a furniture store in a suburb on the other side of town, my process went something like this…

1. Get in the car and start driving in the general direction of my destination.
2. Once in the general vicinity of the destination, consult a map or get exact directions from a knowledgeable human.

This makes perfect sense to certain kinds of people, but various of my friends and past significant others found it absolutely maddening. How can a person get in a car and start driving if they don’t know exactly where to go?

I was thinking about this today in the context of product development. Recently, I wrote about the value of “process,” and I think this makes for a pretty good analogy.

The Web is a very forgiving platform in the sense that building things for it is very easy, and making changes is often trivial. It’s all just pixels and code. I love this because it allows for experiments and mistakes. It encourages mistakes, because you can learn and adjust so quickly.

I have no problem putting something imperfect into the hands of the crowd and then watching it to see how and where it falls short – within reason. If the breaking of something will result in loss of life, or a lot of money, I’m very very careful of course, but such situations are rare.

I have no “brand” to protect – or, rather, a willingness to experiment is consistent with my “brand” – so this is easy for me.

What’s really difficult sometimes, though, is to get clients and stakeholders to feel comfortable with things unfinished and imperfect. Companies are understandably careful about everything they unveil that has their mark on it. When careful goes too far, however, one pitfall is a culture of fear, where people are afraid to make mistakes or deviate from what is safe and known and familiar. This is the same kind of culture where people are unwilling to deliver bad news to the boss.

Not to venture too far into another analogy, but I once had a music teacher say to me, “if you’re going to make a mistake, make it loud.”

I love this philosophy, but to make it work for a company or a client requires certain controls. Some options are…

• Brand it with beta. This is a popular Web 2.0 approach. Just put a “beta” badge on it, and people will know it’s a work-in-progress.
• Launch a laboratory. Google and Digg have pretty nifty public ones.
• Encourage your employees. There’s no encouragement like time and money. Google, again, is the obvious example. They famously encourage their employees to use 20% of their time to work on side projects. Some of these – like Gmail – have become key parts of Google’s portfolio.
• Limit exposure. Create a panel of people with whom you can share your wild ideas and works-in-progress. Or do live A-B testing, where the experimental stuff is only put in front of people who meet certain criteria.

That’s four ideas, and there are certainly lots more, so get in the car and start driving. Make loud mistakes.

In my post yesterday, I questioned the value of “process” in web and software development and discussed my successes and failures both with and without it. The biggest problem with process is that it deludes people into thinking they have the fundamentals in place to guarantee a successful project. Process is too often a crutch in this way.

Over the course of decade and a long list of projects, I’ve worked with variations of waterfall, agile, RUP and other methodologies, and I’ve also done my share of winging it with no formal process at all. Process or not, I’ve learned that the successful projects I’ve worked on all had certain ingredients in common. Namely…

Smart people.
This is a no-brainer, but a team of smart people is key because smarter people work faster, make fewer mistakes and are able to adapt to unforeseen changes. All it takes is a one weak link, however, to cause things to break. You can’t rely on smart people alone.

Leadership.
A film has both a producer and a director. A restaurant has a chef, a manager and a maître d’. People need freedom to lead their respective domains, but smart people inevitably disagree with each other, and smart people without a recognized leader is a recipe for scope creep in the worst possible way. Everyone wants to put their best work into the mix, and a committee approach encourages quantity of ideas. Ultimate power needs to roll up to a single, clear authority with the tools to make good decisions and resolve conflicts within the team.

Constraints.
Frank Lloyd Wright once said, “Man built most nobly when limitations were at their greatest.” Jason Fried of 37 Signals says, “Embrace constraints.” Artists recognize that constraints help focus one’s creativity. In web and software development, constraints usually come in the form of hard deadlines or agreements around scope (often a bit of both). But constraints must be balanced with “a healthy disregard for the impossible,” as Marissa Ann Mayer – VP of search products and user experience at Google – put it. Innovative ideas by nature will often push at the very edges of constraints, so there should be some flexibility. The key to balancing constraints with a “disregard for the impossible” are good filters for managing new ideas. Which brings me to…

Filters.
You don’t want to discourage innovative, unconventional ideas, but you need some way to filter them. The same goes for the more typical dynamics that lead to scope creep. Stakeholders second guess their decisions. Important customers complain about something or make specific requests. Some jackass in a meeting spouts off about some edge case, and boom… more stuff to cram into the project. Leadership (see above) is important here, and so are constraints like deadlines and scope. New ideas mean an increase in scope, which means moving the deadline. Either that, or something already in scope drops out. Each incoming idea needs to be considered, scoped and prioritized against everything else. Edge-case thinking just needs to be stopped. This is what I mean by filters – a change-management process that the team leader needs to enforce. Too often, outside ideas are subject to this process, but ideas originating within the team get a free pass. Filters need to apply to everyone equally.

Simplicity.
This is its own kind of filter. The team and the stakeholders need to understand the essence of the thing they are building. They need to look at it holistically and know what it needs to do in order to be considered complete. It’s important not to look at features in isolation, because this encourages people to explore every possible expression of every nook and cranny of every feature (edge cases again). Instead, the team needs to determine only what is essential to each feature as it relates to the whole. Finally, the team needs to understand that the product can grow and evolve after it’s launched, so “complete” doesn’t mean perfect.

An understanding of “X” factors.
I mean “X” as in multiply. There is a list of things that add risk to a project and multiply its challenges and complexity. I’ll discuss these in detail in a follow-up post, but among them are:

• nature of client
• size and “spread” of team
• complexity and novelty of the thing being built
• time between designing and building
• depth of QA
• distance – with regard to both time and personnel – between deployment and maintenance

Good Tools.
Smart people can survive with just email and whiteboards. That might be the bare minimum, but I’ve had good experience using wikis and simple PM-ware like Basecamp.

Padding.
Because shit happens. A good project manager knows it’s necessary to add 50% to every individual person’s estimate of time and effort, and then add another 20% or so across the board for good measure.

A good contract.
Too many contracts are essentially crafted by BD people who don’t understand what a project will really take, and who don’t have a vested interest in whether it actually succeeds. Too many contracts fail to consider the “X” factors, or encourage constraints, simplicity or leadership.

Transparency.
Otherwise known as communication. But “communication” is a cliche, and every team thinks it’s doing a good job communicating to stakeholders. The bottom line is, stakeholders need a strong consensus around the essence of the thing being built. They need to understand the change-management process (filters), and they need to see steady progress.

Even knowing all this, I’ve still worked on projects that have gone awry. But it has always been because we failed to follow something on this list. The good news is, when a new project starts to take a southward turn, I just take an inventory of the ingredients above, and when I identify what’s missing, it’s usually not too late to put the project back on track.

UPDATE: There’s a Part 2 now.

When I started in the web development business about a decade ago, I worked at a small agency with a few smart people, and we were basically winging it. As the dotcom bubble expanded at a frenzied pace, we grew along with it, and inevitably we had a couple of projects take sharp turns south. People suffered on both sides, and it became clear that winging it was not scalable.

We needed a process – one we could articulate to clients, propagate through the organization and of course put into action in a repeatable way.

This is what “process” is supposed to do. It exists to mitigate unpleasant surprises by telling stakeholders what they can expect from a project. It’s also supposed to save teams from continually reinventing the wheel.

I worked with my bosses at that first agency job to define such a process, and we were very proud when it was complete. Some months later I left that job for an agency on the West coast. As it happened, I arrived just as this company too was in the midst of a campaign to define a process. People from every part of the agency worked on it for weeks, and the final product was a lovely thing to behold. We made posters for the office, and glossy booklets to give to would-be clients.

My next company – a large telecom – used a version of RUP that was the most over-engineered process I’ve ever experienced. When they laid me off, I returned to the agency world. I worked for two of the biggest interactive agencies, and both had processes that were beautifully-rendered in company collateral.

It might not surprise you to learn that all of these processes looked pretty much the same on paper – characterized by big phases with catchy labels. In fact it was only in these labels where the various processes really differed – one company’s “explore” is another’s “discover.” Even the language the agencies used to sell their respective processes was the same, with a lot of emphasis on words like flexible, adaptable and proven.

Finally, it’s worth adding that all of my agency work was in the service of clients who had their own processes, so at one time or another I’ve had to use variations of waterfall, RUP, agile, spiral and triple lindy. Kidding about that last one.

They all share similarities, but the really striking thing these processes have had in common in my experience is how quickly they broke down and became meaningless when put into practice – even by solid teams of nothing but smart people.

I had been a big believer in process, but because of repeated failures I eventually came to see the whole idea of “process” as a fantasy designed to woo clients and placate bosses. I began to believe that assembling a small team of really smart people and simply allowing them to wing it is the right approach after all.

At the very least, this approach doesn’t raise false hopes. If projects are destined for chaos or collapse, isn’t better not to expect them to go smoothly in the first place?

I’m joking of course. There are many reasons projects go south, and there are many ways to help make sure they don’t. Working within the framework of a heavy duty process is not the solution, but having no process at all amounts to blind luck, because successful projects depend on the right mix of a whole range of ingredients that aren’t likely to converge if you’re just winging it.

This is starting to run a bit long, so I’m going to push the rest to a sequel. In Part 2 of this series on process, I’ll talk about the ingredients that need to converge to make sure projects go well.