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.

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.

When it comes to any service that someone provides me, be it changing the oil in my car, getting a haircut, or even serving dinner at a local restaurant, providing me with good service always comes down to how well and how timely they communicate with me.

Are you running a little behind so my appointment is going to be a little later than expected? Or maybe the kitchen is out of what I ordered? All I ask is that you treat me the same way that you’d want to be treated in that situation and communicate those changes to me. Set and maintain my expectations throughout the experience and it’s highly likely that I’ll have a high opinion of my experience when I leave, even if it was a little late or not exactly what I wanted.

When it comes to servicing your website or web application, we here at Galvin believe those same rules apply. It’s because of this dedication to provide good customer service that we’ve implemented a structured support protocol that focuses on keeping our clients in the loop about the budget and timelines of their various requests.

A typical support request with Galvin would play out like this (see diagram as well):

1. Client reports request via email or phone to our dedicated Support Manager.
2. The Support Manager opens a Support Ticket and the client receives an automated email that a ticket has been opened on their behalf.
3. A confirmation email is sent to the client that restates the request and establishes a baseline for the cost of the completing the request and a completion date.
4. The client then confirms the request and the Galvin team begins work on the changes.
5. After the changes are completed, they are uploaded to a secure test server and a link is sent to the client so that they may review the changes prior to them being made public.
6. Once approved, the changes are pushed over to the live website or application.

As you can see, the entire process is focused on clear communication of budget and timeline so that the expectations are set and maintained right from the very beginning.

Now, what does this really mean to someone who does not necessarily manage projects every day? In short, a deliverable is any officially documented information that is critical to the end product of the project. For example, consider the screenshots of a potential new homepage design or the list of things that your organization knows that the new mobile application needs to have. A deliverable is these types of information that contain documented traits that are crucial to the end product.

Now that we’ve highlighted what a deliverable is, it’s important to understand exactly how many deliverables are available for a given project. Sometimes this can be tricky as the types of deliverables critical to a project is dependent upon the industry you are working within. Take that space shuttle that is one day bound for Mars for example, that project is so large that it’s likely to be broken down into many smaller projects…each of which might have 1000′s of deliverables.

As you might guess, producing deliverables takes time and we all understand that time is money. If you connect all of the dots, you’ll start to understand why NASA spends an average of $450 million dollars per mission….it all comes back to the number of deliverables (tangible documents that are critical to the end product) that are required to complete a project.

Luckily, it’s not likely that a web site or web application project will require 1000′s of deliverables or a 450 million dollar budget, but the analogy still works. Identifying which deliverables are crucial to your end product and, conversely which are not crucial to achieving project success within the most cost effective budget structure possible.

The process of indentifying which deliverables are included and excluded is called “tailoring” and relies heavily on experience within managing similar projects successfully. Galvin has successfully completed all kinds of projects, from complex Insurance Rating Software Packages to the simplest of websites. This helps to ensure that the deliverables produced are the right ones for your project, ultimately delivering a superior product at the lowest cost.

For more information on the concept and types of deliverables or on how to better select which ones are the right ones for your project, please give us a call. We’d love to chat more.

Theodore Roosevelt wanted to "Make Dirt Fly".

I think Roosevelt was one of our greatest presidents and a great example of being a leader but his request to “make dirt fly” cost the Panama Canal project $78,000,000 with little to no results.  When the project began in 1904, chief engineer John Wallace planned that he would need a year to plan out the Panama Canal project and ensure it gets done correctly and efficiently.  President Roosevelt and Washington leaders grew inpatient and demanded Wallace to “make dirt fly”.  So Wallace did as he was told and he started to dig the Panama Canal. Ultimately, the lack of planning lead to one mistake after another and the project was not going well.  As a result, the Washington leaders got more involved and in my opinion started to micro manage the project, thus creating restrictions, unnecessary suggestions and ultimately lots of frustration.  Wallace resigned in 1905 after the government spent $78million on a project that was almost canceled.

Wallace was replaced by John Stevens, who immediately saw the disastrous project and took steps backwards and restarted the project by building the foundation, infrastructure, railways, surveillance and budget.  After much research and understanding, Wallace had to make dramatic changes to the project scope when he realized the canal had to be built with locks and dams instead of just digging a sea level canal.  Stevens re-scoped the project and set forth a new plan based on a specific set of requirements and budget, ultimately managing the project in great success.

PBS American Experience "Make Dirt Fly"

Whether you are building a waterway canal, a website or an application, the project can get derailed if the requirements, scope, budgets and project plans are not set forth correctly.  I am not sure what project management tools Chief Engineer Stevens used but when managing a web or software project a work breakdown structure (wbs) is an ideal tool to create the project management plan, define activities, estimate cost, determine budget, plan quality, identify risks, and plan any procurements.  The WBS organizes and defines the total scope of the project, and represents the work specified in the current approved project scope of work.

We hear it a lot from client executives that they want to start seeing our developers write code and our designers create the user interface (i.e. make dirt fly) but our project management team is adamant about documenting the requirements first. If President Roosevelt allowed Wallace to spend the year planning out the requirements for the project then the project could have been completed two years sooner. Without a doubt, if a website starts without detailed requirements then the scope of the project will be delayed and expectations missed. Without the WBS,  the production team is only placing assumptions on how the application is supposed to work. This isn’t ideal because those assumptions can result in missed expectations and rework, which typically cause timeline extensions and budget overage. Doing diligence upfront in the project by properly documenting requirements and planning the project will dramatically improve the chance of meeting deadlines, budgets and expectations.

With Wallace as the chief engineer President Roosevelt could have been defined as a failure as a project sponsor if Wallace didn’t resign from the project.  When Stevens took over his leadership and attention to detail got the Panama Canal project back on course.  From 1905 until completion President Roosevelt and John Stevens made good “project teammates” and Stevens was able to make President Roosevelt a successful project sponsor.

The work breakdown structure is a great tool and ultimately defines the scope of the project.  It is then up to the project manager to manage the work breakdown structure to every detail.  In 2010 Galvin was 100% in “on-time and on-budget delivery” because of our project managers being attentive to the detail in the work breakdown structure.  Managing scope is critical to the project, the budget and ultimately the relationship.

We are well aware that our industry is fragmented. There are many web and software development companies within the Indianapolis area. We can all do great designs, solid infrastructures and proper coding but we honestly feel that at Galvin Creative Technologies we can set ourselves apart with our project management processes. We truly think of ourselves as more of a professional services company opposed to just a web and software development company. We value the relationship, the budget and the timeline of the web or software project.

Two weeks ago I was visiting a client and I stopped by one of our contacts office and asked him how things are coming along with the project. His comment was music to my ears. He said “you guys should write a book on your processes.” He was thrilled with the amount of detail that was involved. He went on to say that he knows exactly where we are with budget, timeline and tasks. Then just last week we helped the Secretary of State’s office develop and launch their Rethinking Redistricting website. What should have been a two month project got done in two in a half weeks and came in well under budget. It was a project that came to us quickly with a very tight deadline and a strict budget. Our project managers put together a two week timeline, while not shortcutting any of our processes, then accurately defined the requirements, then developed it and we nailed it.

In our six years of business I specifically look back at how we have grown over the past two years and what we have learned. We experienced the pain of not managing a project correctly and we have experienced the pain of not allocating our resources. But before things got out of hand we knew exactly where we had to improve and began to invest in our processes, business analysis and project management. Now, our projects are on time and within budget. Tom Schaetzle, our VP of Professional Services, has implemented very rigid project disciplines for Galvin Creative Technologies and the projects we develop.