Months after putting the book on hold, I finally received and read Wait by Frank Partnoy. It was worth the…

…

…

…Wait is a Big Ideas Book ((Wired, rightly pokes fun at the genre with their “Big-Idea Book Generator” to “Concoct a Best-Seller.”  If you look at the cover of Wait, it’s amusingly similar to Wired‘s spoof.)), a genre that some people trace back to the Malcolm Gladwell classic, The Tipping Point. ((In fact, Partnoy even spends times discussing another Gladwell book, Blink.))  In Wait, Partnoy examines different types of decisions—the unconscious-yet-controlled reflex required to hit a baseball, the snap judgement of a job applicant by a resume screener, or the quick analyses of situations required by EMTs and firefighters—and discusses how the people who are best at these decisions do two things to get a positive outcome:

1. Delay committing to an action until the last possible moment in order to gather as much information as possible. Then, acting quickly.
2. Correctly balancing the use of intuitive expertise developed over years and conscious deliberation in response to the present circumstances.

The second point is what I find most interesting: the importance of strategically using expertise and recognizing situations (or parts of a situation) when that expertise may not apply. This, in turn, has me thinking about project management and collaboration.

Solutions can be Standardized…

I run MRW Web Design on my own. I’m the boss, project manager (“PM”), designer, developer, and trainer. Many of those skills, particularly development, are built up over time through lots of reading, training, practicing, and trial-and-error during project implementation.

Over time, I’ve become a much more efficient coder. Some of that is through the use of patterns and code-snippets that I can reuse, having perfected them on prior projects. ((For instance, every custom WordPress theme I build starts with the same set of 33 files that layout styles and functions that I use on most projects (it’s faster to delete a few things I don’t need rather than to rewrite things I do need).)) Other efficiencies come just from decreasing the time it takes to recognize and resolve common problems. Even if I’m building a website with a unique design or trying to fix a bug I’ve never seen, I can use my previous experience with similar-enough projects and problems to get the work done faster.

What I mean to highlight here is not that I’m a robot who makes websites, but, rather, implementation of a website is a mostly replicable process that can take a common input—a picture and specification for the desired design and function—and produce a common output—a working website, theme, or plugin.

…Needs Cannot

Client intake and project planning for a website are fundamentally different from building a website. If you’re a client at MRW Web Design, here’s how your project starts:

1. First Contact
   An email, phone call, or in-person meetings starts us toward working together.
2. Early Discovery
   A discussion laying out a bare-bones overview of the client needs ensures the client and I are on the same page.
3. Project Proposal
   A document formalizes the needs of the client and their desire to work with me.
4. Additional Discovery
   More conversations flesh out the details of whatever will be produced by the end of the project.
5. Everything Else
   The final part, discussed earlier, is the design, coding, writing, communication, training, and whatever else actually makes up the meat of the project.

Looking at that process, Steps 1-4 develop the inputs that define the output created in Step 5. Those first four steps may look formulaic, but they’re not.

Every single project I do varies in important ways from the ones I’ve done before. A project can reuse specific solutions from other projects, but determining which solutions to use and when a new one should be developed is a hard process and is determined entirely by the client’s needs. (Remember, I try to assess needs, not solutions.)

When solutions are proposed too early or when clients might get better service from another website builder, the end result is never as good as it could be. My goal is to give my clients the best possible website to meet their goals, serve their audience, and improve the world. And so it’s important that I make well-informed decisions at every step of a project, even when that means turning away ((Though I offer many skills and services, that breadth can only come about by focusing on a limited subset of each discipline.)) or changing the direction of a project.

Walk to the start. Sprint to the finish.

What Wait has helped me realize is that even though the beginning of each project has some standard phases, the details of those are never the same. It’s inconceivable that I would be an expert in the specific, unique needs of my clients until I’ve worked with them. But when it comes time to implement the project, that’s when I can draw on and apply the knowledge and experience from every project I’ve ever done.

The implications of this are a little odd. The beginning of a project is often the most exciting. Everyone is enthusiastic about the idea of getting something new, and it’s common to want to skip ahead to the project’s implementation (Step 5, above). Everyone, myself included, likes shiny new things! But what that new thing is takes time to figure out, and I can’t shortchange that time if I’m going to give my clients the best services that meet their needs.

Putting This Into Practice

So when I begin projects:

• I must be deliberative and not rush to start building things.
• I must make sure the client is a good fit for my services.
• I must make sure I understand the client’s needs before proposing solutions and discourage clients from asking for solutions immediately.

After the project specifications are set, I can go into a cave and pump out whatever the client needs as quickly as possible. That’s the moment I can swing the bat to hit the home run that I already know is going out of the park.