Top 3 Mistakes Agencies Make

If you are an agency or in-house web designer or a web project manager you will recognize some if not all of these mistakes. If you are about to do a large web project and haven’t made these mistakes yet make sure you read this!

How do I know these are the top 3 mistakes? I made them myself, over and over and over again.

At my agency I made these mistakes during the sales process, during the beginning of the project and all during delivery. The results were usually a combination of pain, unhappy clients and or/teams and a lack of profits. I worked REALLY hard to figure out and to develop simple tools to help overcome these mistakes and I wanted to share my experience with you.

Mistake #1: You WAG it!

Mistake #1: You WAG it!

Congrats, you just sold a website! And you just guessed on the price and scope! Why? Because you are a bad ass designer or coder or agency. This works a few times when you are small, but if you try to do larger projects it’s not so easy.

I used to walk into sales meetings and show people how great of a designer I was. “Check me out biatches! Of course we can design and build that for you!” This was usually met with crossed arms and blank looks. “Why is this guy telling us this, we already know, that is why we invited him in to talk to us.” I really thought that I was selling websites.

When your client or your boss (The CEO or VP of Marketing) comes to you for help, they usually come in and ask in a “20th century” style; “I want a website with this, this, this and this. Can you build that for me?”
You of course being the ever pleasing awesome person that you are quickly blurt out; “ For sure. We can do that for you.” Even before you even have a moment to ask “Why or what problem are you solving?” After all you don’t want to get fired. Or better yet, you want to close this sale and get some food on the table.
Now comes the part where you figure out how to price the website. Tip: Your estimates will always be wrong.

I did this over and over again. Sure we did some great sites – even if we estimated incorrectly and we issued tons of  change requests – telling the client we had to charge them more. It became obvious that I needed to figure out a process to define and estimate what we were selling.

Soon enough I discovered that as an agency I was not in the business of “making websites” but instead I was in the business of solving business problems online. Until we understood the business problems we couldn’t  even start the conversation about what to build and how to build it. The problem was that everyone wanted an agreement before signing a contract. Which after all is how we have done business for centuries. So how do you agree to do something that you know that you can’t completely predict?

Here are some options:

  1. You guess. Make it up. AKA WAG “Wild Ass Guess”  AKA You lie. (Not too cool and somewhat risky)
  2. You tell the truth. “Mrs client, I have no idea, it can be $100 or it can $100,000….” (Ain’t going to fly too often)
  3. You spend a week or two figuring out the solution with your team. (Might as well have lied, cuz now you worked for free for two weeks)

I figured out that we really were “business consultants” in addition to being designers and developers. So I had to figure out how to really solve our clients problems? But I wasn’t a business guy! I asked myself; crap, how do I do this with my serious ADD and being a creative and all that?
And how do I do this when my clients do not want to spend 2 months and $100k to have us figure out their business problems! They “wanted a website dammit!.”  If they wanted business consulting they would have hired McKinsey or Accenture after all. (Those are business consultancies)

To solve this I found mentors and hired people to help me. I also designed a process that was easy for me to use and own. A process that was visual, simple and engaging. We started by developing a series of 3 exercises that we did right at the inception of an engagement. We called them the “Trinity.” And no not the one from the Matrix.
Each exercise was designed to be done in a group, during a one or two day period with the client or team. The goal was to do it together once, and be done with it. That solved two problems; one the issue of time and the second the issue of getting consensus and agreement from all of the stakeholders.  By doing it together there was no back and forth over email and no one that participated in the decision making couldn’t come back later and say that they disagreed.
We did these exercises and other activities to figure out what to build and how much that would cost.  This is often also called discovery. Did we charge for this? Yes. Of course. Not until we completed the Inception (Discovery) did we sign a contract for the subsequent Execution (Design, Build and Launching) of the site.

Mistake #2: You whittle the WAG!

So you already made a “Wild Ass Guess” on how long and how much it would cost to produce the website. Now you focus on designing IT. Meaning the pages, the sections, the graphics, the look and feel, the javascript, the HTML 5, PHP and all that awesomeness.

The problem is that every time you present to your client or stakeholder they have a ton of changes.  So you go back to the drawing board and try again. And then more changes. At some point you become tired and angry and express your feelings. If you are a freelancer and not prone to confrontations you’ll stop answering your clients emails and calls. You disappear. If you are an agency you’ll either use the contract and your project managers to “enforce” revision limits or ask for more money. Those are all fine, but at the end you will end up with a strained relationship and the “product” will be just so-so. No one wins. Or “everyone is screwed.” Whichever way you want to see the cup.

What if I told you that the website (or app) does not matter much. Once you know the technical things such as formats, standards, usability and coding it’s easy to build just about anything.  So the question is not “How should we build it?” but “What should we build?” If your client is a large corporation and they worked internally to figure out what to build they will likely come to you with an RFP (Request for a proposal) outlining the solution. Whether it’s the right or best solution is a different question. The answer is that you really don’t know until you put it out there and have real users bang on it. But how do you validate the solution early enough so that you don’t build a WAG (Wild Ass Guess) and they (The client or stakeholders) whittle it to death until you are forced to launch  because you ran out of time and budget or are just fed up.

What if instead of focusing on designing a website, an app or online product we focused on meeting a customer’s needs? On connecting people in a community that provides value? On solving some tangible problem? What if there was a process that allowed us to validate our decisions at smaller intervals? Therefore preventing rework and endless revisions? What if instead of designing a “product” we simply designed a system in which to find or create new digital products to satisfy our user needs and our business goals?

The second and third steps in the “Trinity” helped us define who our community was (Our customers) in better detail and allow us to design experiences that met their needs.
We also had additional tools in our arsenal that helped us validate and get approval at earlier intervals. These  included sitemaps, user flows, wireframes, paper prototypes, Stylescapes and style guides. Each of these accomplished one very important thing; they broke down decisions into smaller incremental agreements vs building it and having to change it after it was designed or built. We don’t just design a website, webpage or app screens – “Wittle the WAG” –  we design the process around which to design and iterate a living eco-system that helps fulfil the needs of our client’s customers while achieving the global business objectives of our client. I learned to sell and execute the process for solving the problem not guessing a guess of what the solution might be.

Mistake #3: You Actually Think You Can Manage the Project

Mistake #3: You actually think you can manage the project!

Ha! Welcome to your own death. How do I know that a project manager for web projects is seasoned? I know because they want to shoot themselves or change careers. Hopefully the later.
Why is this the case? Well, try managing business stakeholders, creatives, programmers and marketing people that all have different interests and speak different languages? More importantly try managing an infinite set of ever changing variables, without mentioning all of the technology platforms and solutions that you have to figure out and integrate.
You know what comes next; missed deadlines, disagreements, delayed launches, babysitting designers, hounding your developers, lots of calls, lots of emails, (Lots of those), schedules, revised schedules, more revised schedules, late night calls, angry calls. Maybe you start dreaming about emails and conference calls and waking up in a cold sweat.  Does this sound familiar?

Just writing the last paragraph made my heart rate go up. Early in my experience as an agency principal I remember going to the emergency room at UCLA medical center to get an MRI because I thought I had a brain tumor that was causing me constant headaches. After some examinations and $4000 later I was cleared of any brain tumors. Headaches continued though.
A few months later after completing a project we were doing, the headaches miraculously went away!
I was cured! Well not really. They came back when my next project started. Dammit!

So at this point I had to call in the experts. I called Tony Wong. A Jedi level agency account manager and project manager. The kind of guy that you can say “That Account guy has his stuff together.” Over the next several years we successfully collaborated on many projects. He taught me everything I know on how to manage web projects. But it wasn’t until the later part of our journey that he taught me and my fast expanding team how to work in Agile. Some of you in corporate settings might say “Bah humbug, Agile is a crock… “ – fine, it hasn’t worked well for your company. That doesn’t mean that it doesn’t work, it just means that your company can’t make it work. Not judging you or anything. Ok I am.
If you have no idea what I am talking about let me give you the short version of the story.

Imagine a world where you have no master schedule, where you are not aiming at a fixed number of features but aiming at meeting a business goal. Where you have complete transparency between you, your team and your client. They see what you see, they plan when you plan, they see the mistakes, they see the successes.  More importantly they see results fast and frequently. Sound too good to be true? Right?
Sure it does. It took me many years of practice to master Agile.  But when I did, the power I now wield over my projects is nothing short of Luke Skywalker pulling the X-Wing fighter out of a swamp with his mind. Maybe even more powerful.

How is this possible? Well, first don’t try to manage the project. Let the project manage itself. I can hear some of you already thinking, “Dude, what kind of Star Wars mumbo jumbo are you spewing here..” Hear me out believe me later.
What if you just moderated and facilitated the collaboration in an iterative and goal oriented fashion? What if everyone on the team was actively involved and self managed. What if your only job was to facilitate the process of setting the goals, helping the team themselves plan the work and helping them check in on progress and remove obstacles. All you had to do was simply provide the framework for the collaboration and let the magic happen. If you don’t believe me, listen to my clients who have experienced the said magic.

“Their approach to our Web design project was unique, starting with executive workshops to help define our business goals and our user experience. We then were introduced to Agile training which helped manage the execution and really empowered the team to stretch and meet our goals under an extremely tight deadline. This plus great design to boot!”
– Marc Block, VP of Marketing, Line 6

Did you notice that the design was a small line at the end? That the real issue was the process. Again, I am not diminishing “design”.  After all remember that I am a bad ass web designer. But what would it matter if we could not execute and release a successful product? In the 21st century good design goes beyond defining form and function. It transcends disciplines and language. Good design is about designing how we think and how we collaborate.

Regardless of where you are in your own journey, my goal is to share with you my own 16 year journey and the tools I have used to avoid these 3 mistakes. Though working  in the 21 century is very different than the 20th century it should not be painful for anyone! If these tools help provide you with an internal framework, some discipline,  a better overall experience and they help you grow revenue and attain profitability in any way, then I am happy. If it’s inspiring and fun thats even better.

They have worked for me and I know that they will work for you too. So much so that I have dedicated my life to sharing these tools with you. Not to make money (Though it’s nice to live well), not because I think I know it all (I don’t) but because I truly believe that understanding how to collaborate in the context of building software is a framework for building the 21 century. It represents jobs, new careers, new business opportunities and the possibility of changing the world. For me The Skool is not a school, it’s not about web design, it’s a small movement. We just happen to be starting with web design.

“The online classes and kits provided by The Skool has been pivotal in shaping our internal discipline and winning new projects. Within months we’ve seen our agency grow in terms of revenue, profitability and overall experience”
- Scott, Greensky Interactive, London UK


Comments are closed.