Top 3 Web Project Mistakes Agencies and In-House Departments Make
Mar 25, 2013
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.
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!
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!” I really thought that I was selling websites. However, 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.”
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 we 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 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:
- You guess. Make it up. AKA WAG (Wild Ass Guess). AKA You lie. (Not too cool and somewhat risky)
- You tell the truth. “Mrs. Client, I have no idea, it could be $100 or it could $100,000….” (Ain’t going to fly too often)
- You spend a week or two figuring out the solution with your team (might as well have lied, because 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: 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 two months and $100k to have us figure out their business problems? They “wanted a website!” If they wanted business consulting they would have hired one.
To solve this I found mentors and found 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 three 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 could 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.
What if I told you that the website (or app) does not matter much. Once you know the technical things, like 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 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 users’ 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. We don’t just design a website, web page or app screens – “Wittle the WAG” – we design the process around which to design and iterate a living eco-system that helps fulfill 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 what the solution might be.
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 latter).
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 career 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. $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.
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 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? 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 now, 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? The real issue is 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 three 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 that’s even better.
Related Insights
-
-
-
-
Jonathan Saurez
Unit Testing Using AEM Mocks
Detecting Code Flaws Before They Cause Outages for Your Users
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.