Defining tasks before starting the work.

I have had it happen too many times. Do you want to avoid needless back and forth with design work because you were working on a task with no defined boundaries, scope, or functionality – working to satisfy someone else’s mysterious vision?

Client: “I like what you did with A, B, and C like we discussed, but where is D?”
You: “I wasn’t aware there was a D. That impacts the design of A, B, and C. Good to know.”
Client: “You’re missing E and F.”
You: “You never mentioned you needing those before.”
(infinite loop)

You can see how things quickly spiral out of control. You feel awful because the client isn’t getting what they envisioned, your adding rounds of check-ins to the process, you aren’t sure what you’re designing anymore, and you’re wasting time.

You need things defined before starting on the work. I just had the following interaction…

Client: “So after this version I want you to start working on 1.0.”
Me: “What is the difference between the current version and 1.0?”
Client: “1.0 will be public-facing. More hand-holding. Can you have it done by next week?”
Me: “We can have a meeting about 1.0 and define it so that it contains everything you need it to contain.”

I could have just said, “Okay.” I wouldn’t have known what the hell I was going to do though. It’s not my job to be able to read the mind of a client to produce some vision that they haven’t communicated. How can I commit my time and energies to a deadline when I have no idea what is desired?

The client agreed to the additional meeting to scope out 1.0. Now when we leave that meeting, I should have exacting requirements for the application flow, the purpose of all the elements, what the application will be doing, etc. Saving me time, saving the client time, and saving needless stress.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.