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.

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.

This evening I was thinking about the sites I use to work on since I starting working in the web world in 1996.  I recalled how I use to design with wallpaper and tile the background of web sites, the scrolling text, the blink tag, paint shop pro graphics, gray, gray and more gray. Then I began looking online and came across a nice article to read by Design Reviver. I remember these sites and recall how cutting edge they were in 1997, 1999, 2000 and so on.  But then I began looking at sites from 2006 and 2007 and how dramatically and quickly the user interface design has changed.  Simpler is better these days.  There is more concentration on a true guided path and helping get the user to the information they need quickly.  We preach that we don’t want to make the user work for where they want to go.  The simplicity of web site design has improved the user experience.  It truly was fun to go back in time and see all these web sites.

I look forward to what UI design will bring in the coming years.