I had the good fortune of delivering a keynote address at the Web Design 2.0 conference in Las Vegas last month. The conference organizers courageously said I was welcome to talk about whatever I wanted (suckers…). So I gave it some thought, brainstormed a number of things I’ve always wanted to say at a Web conference and came up with the session title and description below. The talk seemed to go over well, from my admittedly biased perspective. So I thought I’d share a summary of what I discussed here on our blog. It’s a little edgier than the stuff I normally write, but I’m hoping you won’t mind. I’ll cover one topic at a time at a completely random schedule dictated by my mood and bandwidth. I hope you enjoy them…

Here’s the session description, for background:

The 8 Things Every Web Team Should Know: Lessons From a Grumpy Web Consultant
Lance Loveday, CEO, Closed Loop Marketing
Anyone who has worked in the online space for long realizes that many of the obstacles web teams face have little to do with technology, and everything to do with the damn humans. Why are web projects so easy for some organizations to get right but so excruciatingly difficult for most? Veteran web guru Lance Loveday knows and it makes him grumpy that everyone else doesn’t. Join Lance as he reveals the dark side of web team interactions, the damage it can wreak and the toll it can have on an organization’s success. He’ll share humorous anecdotes based on in-the-trenches experiences and, most importantly, practical tips on how teams can work smarter and more effectively.

#1 Kick Ass or Suck

Either path is OK. But you have to choose.

My experience has been that most web projects produce mediocre results, at least relative to their potential. That’s always frustrated me, especially when self-inflicted wounds are to blame for underperformance. I’ve struggled to find a solution for this recurring phenomenon for years. I think I may have found something.

I saw Jason Fried from 37signals speak a few years ago, and something he said about web projects has stuck with me ever since, and provides a good introductory framework for the point I want to make. He said there are only three components to web projects: Scope, Budget and Time. He then said they told their clients “Choose two” (this was back when they still did client work). Clients then had to consciously choose to flex in one area in return for making a change in one or more of the other areas. As most clients opted for a fixed budget (shocker), they’d then trade off increases in scope for extensions to the project timeline. I always thought this was an enlightened, if not always realistic, approach to client management.

While that approach works for maintaining an equitable relationship between client and agency, it doesn’t address the ultimate success of the project outcome. The bigger question I’ve always struggled with is:

What’s the right way to scope a web project to maximize the potential for success?

Conventional wisdom and the American work ethic assumes that your success in any project is directly related to your effort level. In chart form:

How We Wish Things Worked

I subscribed to this philosophy for a large part of my life. But my experience with web projects over the past 10 years has led me to believe that this curve actually looks more like this:

How Things Actually Work

Suck By Design

Under this scenario, the incremental effort between the first and last points is substantial, but the incremental gain is minimal – meaning a poor ROI on that incremental effort. In this case, you’d be much better served by consciously choosing to limit your effort to the first point, and freeing up your resources to focus on higher ROI activities. I’ve labeled this area of the chart “Suck” because it represents a relatively low effort level. “Suck” usually refers to something that, well, sucks. If you try to kick ass and end up sucking, then you’ve failed, and that truly does suck. But sucking in the way I’m describing can be good if you do so by design. I actually recommend sucking in this scenario, because sucking will get you the best return on any reasonable level of effort.

While effort in my example could be comprised of both Scope and Time, I advocate bounding effort with Time. Why? Because there’s nothing like a hard deadline to achieve focus. When you have to deliver a project under pressure, it becomes a LOT easier to prioritize features, focus on what’s truly important and ignore the less important stuff. The reality of most web projects is that you rarely know ahead of time exactly how things are going to turn out. There are thousands of little subjective decisions made along the way, any one of which could cause to you to see the project in a new light and/or give birth to a new idea that has the potential to make a huge difference in the success of the project. Attempting to rigidly control a web project’s scope based on an early assessment of what you think you need runs counter to the exploratory nature of web development. It’s also no fun. Many of the people who work in the web space do so because it fulfills their need to be creative in some form. Rigidly adhering to a fixed scope takes a lot of the creative joy out of projects. It also limits the ability to integrate user feedback obtained along the way, assuming user testing is a part of your development process (still a rarity, sadly).

I acknowledge the difficult balancing act involved in keeping a project on track while still enabling some freedom and flexibility. It’s very difficult to suck successfully. But not impossible! I’m encouraged by the examples I’ve seen of companies who do this well.

Can’t Suck? Then Kick Ass!

Sucking just isn’t palatable for some organizations. Tradition or company culture may require you to go big on all projects. And that can be OK if you can truly afford to invest at the higher cost Kick Ass level. Planned and executed well, big projects can achieve the higher success associated with Kick Ass status. These projects can also be a lot of fun. But because they usually involve more people, they tend to involve more politics and lack the camaraderie of a sucky project. Still, I’d always rather engage in a Kick Ass project than get stuck with the last kind of project – the dreaded Mediocre Middle.

Avoid the Mediocre Middle

Notice that I qualified my comment about Kick Ass projects by saying they can be good IF you can afford to invest at that level. The problem is that most organizations can’t afford to invest at that level. But they won’t settle for sucking and they want the Kick Ass results, so they fool themselves into thinking they can get there by cutting a corner here or there and end up investing at a level that puts them somewhere in the middle – essentially guaranteeing mediocre results. I argue that most companies set themselves up for failure from the start by having unrealistic expectations and improperly scoping projects.

If this is the source of the problem, how do we fix it? The easy answer is to plan better, be more realistic, be militant about avoiding the Mediocre Middle, suck by design when it makes sense, and adapt project management processes to embrace the semi-anarchic nature of web work. But that just isn’t realistic in most organizations. Until the company leadership and culture can support this type of approach, your best bet is to try sucking on a small scale. That’s right: Go rogue. Choose a side project, dedicate a small team to it, lay out a vision and requirements, set a hard deadline for completion and turn them loose. If that shows success, socialize the results internally and try to get more small focused teams dedicated to short-term projects. Call them Tiger Teams, Strike Teams, War Room Teams, whatever works. You have to start somewhere.

What do you think? Is this realistic? Too radical? Managing projects in this way requires a whole new approach. Some within the agile development community are already doing this. And a number of organizations are dabbling with some of these concepts. Will it ever go mainstream? Probably not. But my gut feel is that those organizations who adopt this approach to project management are going to seriously outperform.

I’ll address some of the leadership and culture issues that play into this issue in future posts in this series. Next up: Don’t Hump the Shark.

For more on 37signals and their approach to agile development (the concept upon which these principles are loosely based), see their fantastic book “Getting Real.”