Call Honest Code at (619) 800-0116

Planning to Plan, Part 2

August 31, 2010

For many projects, there is a very simple reason why the final invoice winds up being more than the estimate: The project at the end is different from the project at the beginning.

Let me back up. At the beginning of every project, there is a plan. I usually write a statement of work that defines what exactly we’ll be delivering at the end of the project. (This is also sometimes referred to as the project’s “scope.”) It’s basically a preview of your receipt. If all goes well, at the end of the project, you’ll get an invoice for the same amount with the same things on it.

Recently, I’ve had a few potential customers call, expecting to use the development process as a way to flesh out their ideas. They think that developers can just start writing code without a definite plan as to how the whole product will come together at the end. “We’ll work that out as we go,” they say.

Say our project is to win a formula-one race. We have a top-of-the-line car design, and we’re installing only the finest engine and using the finest fuel. It’s sure to be a winner. However, if the finish line to our race is draped between two other cars ahead of us on the same track, our project won’t have a fair chance of finishing — let alone winning the race.

No mainstream project — racing, web development, or otherwise — has ever succeeded like this. Moreover, successful projects can describe their plan in a just a few words that anyone can understand. “Our project is to win a formula-one race.”

Augmenting the service offering part-way through is usually doable, but is oftentimes not desirable. “We want the driver to enjoy high-tea service during the race.” Sure, let’s build in a crumpet box and a china cabinet, and we should be all set. Our description gets a little longer (and more bizarre), but it’s not breaking any laws of thermodynamics.

The project, at the beginning, was building the car. Now, at the end of the project, it’s two things: building the car so the driver can enjoy tea during the race. It isn’t to say that the project hasn’t gone to plan: The car can still win the race. It’s just when customers change their mind part-way through the development process, they oftentimes don’t anticipate that the decision will affect the final cost. Tea sets cost money, you know.

Not that changing your mind is a bad thing — if a bolt of lightning strikes you in the middle of the night, and you realize that a particular feature absolutely requires modification, it can be done. It just means going back and adjusting the plan. Adjusting the plan just means adjusting the budget. If we can’t alter one, then chances are we can’t alter the other.

Thinking for a living

May 27, 2010

I come from a working family. My dad’s side of the family were almost all employed by the railroad; My mom’s side almost all employed (at one point or another) by Paramount Studios. The word “work,” to me, means spending time doing something, and ending up with a product you can point to and say, “that’s what I did.”

Until recently, I was happy to answer questions and do research for clients whose projects I was working on. It didn’t seem like a huge deal, until I spent an entire afternoon writing an email suggesting hosting options for a client’s web application.

Analysis is almost as important as the work itself. Analysis before, during, and after a project is completed are all equally valuable: Stopping for a second to consider your direction of travel is usually a good thing. While the value of analysis is clear to clients, it turns out that it wasn’t clear to me.

Writing that email, I didn’t think to check the time, or even bill for what I was doing. I’ll just answer this question real quick, it’ll just be five or ten minutes. I enjoy solving problems, and coming up with plans, so perhaps I don’t notice the passing of time quite as easily as with other tasks.

Later, when a (different) client specifically asked for some research on a specific topic — for pay — I was a bit worried. What end product would I provide to her? It was clear she didn’t want anything terribly formal. A report or a PowerPoint would have been overkill. I felt weird about just replying with only an email, so I included a simple chart and some links that I turned up. It turned out to be exactly what she needed.

This is one of the many reasons I love my clients. I never thought of being paid to think, but perhaps it’s something I could get used to.

Planning to plan

May 19, 2010

When I first speak with potential clients, many are flush with the excitement of promoting their new product, or starting a new business. Rightly so: Good clients with truly innovative, interesting products are fun to work for, and their enthusiasm is contagious.

And then there’s Richard. (That’s what I’ll call him, at least.) Richard is a salesman, and he’s found a new angle to sell things (that people already buy) to people (who already buy them). Richard is excited because he sees dollar signs, and he wants boots on the ground toot sweet. Richard is familiar with his industry — very familiar, in fact. His industry is rife with politics, and fortunes are made and lost on relationships alone. Richard has these relationships, and he has this idea that will get him the yacht and the mansion and the Alfa Maserghini. He breathlessly outlined his idea to me in a phone call. But for now, of course, his budget is five bucks, two buttons, and a bottlecap.

The idea wasn’t bad, necessarily, but it was very new. It was newborn, and its fontanelle hadn’t exactly closed up yet. At the beginning of the conversation, the site behaved one way; Near the middle it behaved another way entirely. When I asked about the differences between these two versions of the site, he said, “I keep changing my mind every day. We need to start coding a prototype now and just tweak it as we go.”

Never mind the fact that his ideas are not only changing daily, but over the course of a phone call. Also, ignore the fact that to build his prototype by itself is a five-figure proposition. The excitement of starting his new project was leading him to jump in the pilot’s seat, pull some levers, and learn how to fly on the way there.

I said to Richard, “The day that your mind stops changing is the day you can start thinking about development. Until then, you need to keep refining your plan.”

Planning doesn’t have to be all Gantt charts and functional specifications. Richard’s idea had a bit of a game component to it, so I suggested that maybe making a board game first (out of scraps of paper or sticky notes, even) would be a good way to flesh out his nascent concept. But — as much as he wanted to — it was far too early to get designers, developers and project managers on board.

Richard, apparently, had called me after speaking with a development agency in India, who was ready to get started writing code. This could certainly explain some of the horror stories from outsourced projects: Overzealous clients and a can-do-how-high vendor attitude can be dangerous. Starting development too early means that when you change your mind halfway through, you have a half-baked solution that took half your resources. Not exactly efficient.

As easy as building a website seems to some, it’s still a process. It’s a partnership. We all need to be on the same page so we can get there together in one piece.

Jumping into the pool from the highest diving board may be exciting, but it’s risky.


© 2019 Honest Code, LLC. We love you. Powered by WordPress.
Privacy Policy. Terms of Service.