If you are like me, I took this to mean that the customer wanted potatoes. When the order came up, the customer replied, “Oh, I asked for the fruit cup.” Since overhearing the original order take place, I began to think about what exactly the customer asked for because I’m in the business of gathering requirements from clients so this was all too familiar to me.

Original Requirement: “I’d like to substitute the fruit cup for the potatoes.”

Now this requirement could have been interpreted two ways:

1. Customer wants fruit instead of the potatoes.
2. Customer wants potatoes instead of fruit.

The waiter had a 50/50 chance, in this case, to get the client’s expectations correct. However, the waiter (and I) assumed incorrectly. This could have been easily corrected by just repeating back to the customer, in the waiter’s own words, what the customer wanted: “You would like to have a side of potatoes?” The customer could have corrected the waiter during this point versus having to wait until the order was delivered to only find out it was wrong.

This can happen all too often in any industry, but we experience it a lot in the software development field. You may have seen the infamous comic strip of the “tree swing”, as shown below:

There’s always a small chance for error when acquiring and understanding requirements from clients. Hey, we’re all human, right? But you can help ensure you get them 99% right just by using the following three tips:

• Repeat the request using your own words. Try not to use technical terms. Clients can have a different definition than you or may not admit they don’t know what you mean.
• Draw a picture. A picture speaks a thousand words.
• Ask the question a different way and see if you get a different answer.

Remember, you never know when the client might want fruit and you give them potatoes.

Winston Wolf, Problem Sovler.

This past weekend I found myself getting caught up watching Quinten Tarantino’s 1994 classic gangster film Pulp Fiction. Of all of the great scenes in the movie, I’ve always been most fond of the, “The Bonnie Situation.” In case you don’t recall or haven’t seen the film, The Bonnie Situation is a short part in the film in which two characters, played by Samuel L. Jackson and John Travolta respectively, find themselves in a tight spot.

They are on the run and drive quickly to one of the character’s friend’s home. They arrive announced and park the car in the garage. The friend, played by Tarantino himself, tells them that his wife Bonnie will be home very shortly and that they have to have their problem solved and be gone before she gets home.  In search of someone to help solve the problem, a new character, played by Harvey Keitel, is introduced, Winston Wolf. Once called in, he quickly arrives and announces that, “I’m Winston Wolf, I solve problems.”

Over the course of the scene, Mr. Wolf introduces himself to the other three characters and is very careful to outline who each character is and how their role plays into the problem at hand. Along the way, he shows that he’s not afraid to ruffle a few feathers and that everyone has to listen to him in order to solve the problem by the deadline. He then evaluates all the factors that play into the solution of their problem. He very quickly prioritizes what needs to change with those factors, how those changes will take place, and what is needed to make them happen. He then clearly communicates this to the other characters in the scene. Of course, at the end of the scene, Mr. Wolf and the other characters have worked through all of the steps that he has laid out and the issue is resolved right before Bonnie arrives.

When I first watched this movie while I was in high school, I never realized exactly what Mr. Wolf was in the context of this scene. Now that I’ve worked in the professional world for a number of years, I realize that Winston Wolf isn’t just a problem solver, he’s a Project Manager. Think about it, he:

• Introduces himself
• Immediately identifies all stakeholders
• Evaluates all factors of the problem at hand
• Devises a plan for solving the problem
• Clearly communicates the plan
• Procures what is needed to make the plan happen
• Puts the solution in place step by step
• And wraps everything up making sure everyone is happy and that the requirements have been met in the end

We’ve recently just started a project with a local company who has a problem with a very solid deadline, but no defined solution. In that instance, we are their Winston Wolf. We’ve come in and identified the all key stakeholders, identified the problem at hand, all factors and resources needed for a solution, and are currently in the process of working through that solution with all involved.

While I know it won’t encompass everything that Galvin Technologies has to offer, I really wish we could start introducing ourselves with, “We are Galvin Technologies. We Solve Problems.” It is so simple, but means so much.

Handing that baton off while running full speed is really a lot harder than you’d think it be. Despite how quickly it actually happens in real time, those teams have practiced it many times. The actual handoff occurs with a certain foot forward and a precise amount of time after the recipient of the baton has started moving. Most importantly, dropping the baton means losing the race!

Prior to any actual contractual agreements actually being in place for a project, it’s very likely that you’ve had several, if not many more, planning meetings with a sales-type person and probably even a pre-sales engineer. Think of this as the first lap of the race and playing the role of the baton are the project charter, initial project requirements, timelines, scopes of work, and situation specific details that could immediately affect the project.

In order for actual project, or second phase of the race, to get off on the right foot, it’s crucial that there be a clean handoff of this knowledge, or baton, to the members of the project team. How do you do this successfully? Just like a world class track and field relay team, it takes practice and an understanding of this fast, yet complex, interaction.

For our Galvin team, this occurs during the Project Kickoff meeting. If posssible, we prefer to have all key project stakeholders present. From the Galvin side, the personnel who are present are largely representative of the project scope itself. If its a database heavy application, we include our lead architect. Likewise, if we know that graphic or interactive design is a key component, we’ll include an interactive designer.

Once we’re able to get together there is a specific agenda that the meeting follows. This typically goes something like this:

1) Introduction to Roles and Responsbilities – We want to verify everyone’s role and responsbility in the project. Is there a 3rd party IT Manager who will be making DNS changes? Let’s identify and record that as a part of project foundation. Highlighting it early will avoid miscommunication later. Once again, no dropping the baton!

2) Highlight Project Objectives - This is where we’ll review the project scope of work and the Project Charter. This equates to not only what we’re setting out to do or how we’re going to, but to WHY the project has been authorized. In general, human beings work more efficiently when they understand the context in which they are working. We are at Galvin are no different. Bringing a general understanding of the project’s purpose can often generate new and creative solutions from unlikely places.

3) Project Specific Discussion Items - As a Project Manager, I always felt like this was the most important part of the kickoff meeting. This is because this is the spot where we openly discuss not only risks to the project, but how to mitigate those risks.

4) Next Steps – Very simply, where do we go from here? Next meetings, action items, etc.

At this point, we’ve succesfully handed the project off to the next runner in the race. Just like in a race, however, there are other handoffs that must occur as the project life cycle plays out. We’ll certainly cover these in later blog posts. In the meantime, just be thankful I don’t actually have any photos or videos from my high school gym class. It would be quite a sight!

Just think about how much time and money your organization puts into creating strategic and formal business plans. The meetings and the brainstorming and more meetings…all trying to account for everything, just so you can avoid surprises. We all know it only takes one bad one and the entire plan can be shot.

You might not realize it, but planning for a web site or web application is much of the same exercise. The difference is we call it ‘Discovery’ instead of Strategic or Formal Planning. Discovery has many purposes, but none so important as trying to account for as much as possible to avoid surprises later in the development cycle.

The trick is to consider what is included in that stack of paper. It’s likely a compilation project requirements, risks to the project, and most importantly, plans to mitigate those risks. Identifying both requirements and risks brings awareness of the possible issues to all project stakeholders. In this way, you not only know what you’re building, but what is out there that might trip you up, and how you’ll deal with it if or when it does happen. In short….no surprises!

Think of it this way, you wouldn’t build a house with proper plans. Show me an architect that cuts corners on your house and I’ll show you an architect without a job. If you’re serious about the project, be serious about planning. It really is that simple.

Getting Real

A few weeks ago I brought an old book back out – 37signals “Getting Real”, dusted it off and handed it to one of our UI developers, Travis, to read.  Today, while pouring a cup of coffee, Travis informed me that 37signals does not believe in the practice of developing Use Cases.  I had to look into this more becauase I have been an advocate of this book.  I agree with the 37signals web application development approach and I recommend the book to a lot of people but today I am more of an advocate for the discovery process and especially use cases.  Our software application development methodology follows a rigorous discovery process with many deliverables.  We took this process and implemented it into every type of project and that includes the simplest of web sites.  By developing accurate Use Cases our projects have had much more definition and prevented scope creep.  When doing a build/debug/build methodology relationships get tarnished, costs grow, timelines get delayed and scope creep is difficult to manage.

Everything else preached by 37signals is spot on.  When developing complex web applications the project manager and the client need to define priorities that fit into the budget and the timelines so that the project can go live in a “simpler state”.  After the first launch you better have a good game plan and dedicate yourself to the release schedule you promised.

When a project starts make sure you always go through a Discovery process and define the budget, timelines, priorities, functional requirements, design requirements and technical requirements.  Develop a requirements workbook and from that define the use cases.  Although it seems like a lot of upfront work it pays for itself at the end of the project.

One other thing….test, test, test, test.