How to Know What You Don’t Know

I’ve read that estimating a project is one of the “dark arts.” It’s funny but also true, in some sense. To really get a sense of how to estimate things you, as the person building an estimate have to “know” certain information. Like what? How long does it take to build functionality for task x, y and z, for instance. How long does this design process take from concept to composition? How long does it take to create site content?

Do you know what the exact answer is? If you guessed eleventy-schmicks then, my friend, you are wrong… and you’re not alone, but still so very wrong. A very vague “it depends” is the answer I was looking for. The best we can do in an estimate is to understand. That sounds like a heavy serving of b.s. doesn’t it? Well, what do you want me to tell you. I’m not going to explain why this is all so vague. Other folks have written about that topic better than I could ever hope to.

Asking the BIG questions

What do I, as the client, truly want to do here? I’m building thing A to accomplish thing C, D and E. Whomever a client works with, all roads should lead to this basic question’s answer and how it will be done where it concerns the work to be done and the roles of those involved.

We speak to people who know they need something and they don’t know what it takes to get from point a to point b. Education is a path to understanding; we can sit and educate and explain to a person why things cost so much, or take so much time. Even then, it’s not a guarantee of understanding.

How will success be determined? Often overlooked, this question is equally critical. As professionals, when we build stuff we’re trying to accomplish a goal. Increase clicks, sales, interaction; it’s not just about making something “pretty.” It’s about making something pretty damn useful. A useful site is one that easily helps people give you money. What a novel idea! Think about what a successful project looks like in three months, six months; beyond.

Who’s on Second, What’s on Third?

Sometimes, perhaps most times, the client should take some time to understand the nature of what they are asking. That sounds great but how does a client DO that?

First, it starts with understanding the roles involved in the work being done, being able to identify the “hats being worn,” as they were. Is brand design, visual design, UX a part of the project? Then it helps doing a little research understanding what each role is supposed to do. Now, depending on who you’re working with, the service provider may not have a single person for every role. Many smaller shops are run by folks wearing many hats. That’s common and that’s fine. Sometimes the person running the shop handles your visual design, project management and farms out development to a trusted colleague/resource. Again, that’s typical.

Whatever is researched doesn’t mean that what you find is precisely what that role is relegated to. The goal here is to gain an understanding into the skills that go into making your project the best possible thing that it can be.

This isn’t just about the service provider, it’s about the client, too. Who will make final decisions? Will it be a single point of contact or will it be more than that? This is important to communicate early on. I should note that’s an understatement.

What funky stuff are we gonna use?

What tech is involved? Now, I wouldn’t expect anyone to know every nook and cranny about the technology will be employed with their project. But there are basics to know. Where will the site be hosted after launch? What languages will be used to build this project? Are there any dependencies to worry about? There will no doubt be a lot of questions, at the same time, though, I exercise caution to. Do you know the biggest enemy we face, as a civilization? WebMD. Yes. effing WebMD. If something’s wrong, you go to this site and you enter a symptom and then pick the disease that you like best. What kind of booger-pickin’ diagnosis is that!? It’s not good. I would urge a client researching technology to research relevant usage; the size of the community that supports the technologies to be used. You don’t want to work with a guy building a development framework that only he uses, for instance. Widely used and tested components make the most sense for a project; avoid the fringe if you can.

The Process

Once you have a grasp as to who does what and why and how that fits with your project, you’re ready for the “process talk.” As a client process should be as important to them as it is to the service provider they partner with. A common question SHOULD BE “What is YOUR process like?” That’s a question I don’t get enough of, yet I always explain what that process is.

Understanding the order in which tasks are done is helpful. You may here words such as “Agile” or “Waterfall” and “Scrum” and more, but don’t get caught up in them. Understanding how the work fits with the roles is what we’re working with and also understanding the order. Order of operations aren’t just for math, people!

What’s it all cost?

“It depends…” Yes, it applies here, too. Different providers have different capacity and overhead and provide different value and most charge, hopefully, commensurate to the value that they bring to your project. On top of that, in this industry, there’s a bazillion ways to approach any project. Knowing what is a part of the project, what pieces, roles and process will hopefully begin to figure out what all is required to make your project go. You can “Google” what a web design/development project will cost; you will find cost estimators and more. I think that one defines cost based off a perceived value that the project brings to you and/or your business.

Tl;dr

I think the biggest takeaway here is to ask questions. Lots of questions with the following in mind.

• What is the goal of the project?
• How will you and your client determine if the project is successful?
• Who will participate from the client and provider end?
• What range of services does the project require?
• What is the process involved to get from point a to point b?
• Is there technology involved? If yes, what is the technology?
• Does your client employ anyone with expertise on the topic?
• What is the timeline for the project, and will your client require your services after your work is complete?