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.

So obviously there are plenty of people that still need to know why they need one. Below are some of the most common reasons that businesses do not have websites and why those reasons don’t hold up under further scrutiny.

1. My business doesn’t need a website.

Nothing could be further from the truth. I’m not saying that there aren’t some exceptions to the rule, but I can hardly think of a single type of business that wouldn’t, in some way, benefit from having an online presence. According to InternetWorldStats.com, in North America alone, there are about 270 million internet users. That’s roughly 80% of the population. And if your customers are global, that’s only 13% of the world’s internet users. Let those numbers sink in for bit. To choose to not advertise to that many people is unthinkable.

Even if your company doesn’t exactly sell something online or provide a service that uses the web, you’d be surprised still at how many people will seek information about you from the internet first, before any other means.

2. It’s too expensive.

I have two thoughts on this one; the first one being is that it isn’t as expensive as you think. It really depends on what you want your website to do. A static, brochure type of website will cost a lot less than having your own Facebook. Its important to first find out what your needs are as far as an online presence. If you find that you need a large and complicated site, odds are that this article doesn’t concern you anyway because you already know that you need a website. Static brochure websites aren’t expensive at all compared to other forms of marketing. With the right planning and forethought, the entire process can be streamlined into a very inexpensive and cost effective project.

My other thought on this is that, while the goal is to not spend too much on a website, you also don’t want to spend too little. Sure, your teenage nephew might be able to make a website, but I’d be highly dubious of how professional and effective that website would be when it’s completed. A website is your online business card. To many customers, it will be their first impression. You don’t want that impression to be that you are unprofessional and unwilling to put effort into your own website.

3. It takes too much time.

On the contrary, having a website can actually save you a great deal of time. The time involvement is front loaded. It may require extra time while creating the site, but once it’s done, it’s done. Adding additional content is, in most cases, relatively quick and easy. And again, the time a website will save you in the end in invaluable.

For instance, simply making a well thought out Frequently Asked Questions (FAQ) section to your website can not only save you time from having to repeatedly answer the same questions and concerns, but it will also save your customers time as well. Putting some photographs of the product or service on your site will ease customer concerns and keep you from having to explain things that can be said with images.

That is just one example that will open up large amounts of time for your business. I could probably write an entire post of the time-saving benefits of a website, but I’m sure you get the idea.

4. It’s too complicated.

If you are trying to create a website yourself and you don’t know a thing about web technology, then yes, it will most certainly be complicated. However, if you are having a website created for you, then no, it’s not complicated at all. As I said in the previous section, once your website is done, it’s done. Adding and updating content is relatively easy at that point, especially if you have a good Content Management System (CMS) to make things even simpler for you.

Once again, giving the proper forethought on what you want your website to do will be what you spend most of your time thinking about. The process of making your website live can be handled by most web development companies. This makes the process of having an online presence much less complicated and painful than many people think.

So as you can see, there aren’t many compelling reasons to not have a website for your business in today’s world. By not having one you are missing out on, literally, millions of potential customers. You are opting out of one of the most cost effective forms of marketing. You are more than likely using up your valuable time doing tasks that your website could be doing for you. And you are not utilizing one very simple and powerful tool to promote your company, vision, and ideas.

Every project manager knows that with any project that falls outside his or her comfort zone, it induces a level of unavoidable risk. Some project managers thrive on this risk and are able to haphazardly proceed with flying colors. On the other hand, some project managers buckle under the pressure and are not able to deliver a sound solution to the client. There are some project managers, however, who are able to navigate through this risk and achieve a balance that allows them to understand, accept, and manage this risk.

As the senior project manager at Galvin, I identify with the latter pool of project managers. I do not mind the risk that comes with uncharted territory; it keeps me on my toes and pushes me to think critically and creatively in bigger and better ways. However, it is important for me to understand what it is exactly it is I am getting into before any decisions are made.

The Challenge

Most recently, I ran up against this unfortunate predicament: our client needed a solution in which the time and budget did not allow for us to be able to utilize the best of our internal resources to develop a fully-customized software solution. Thus began my challenge to discover how to deliver an end result that would be able to exceed the client’s expectations while being considerate of a strict timeline and budget. To ensure that I am leading the client down the right path, I rely on the following four tips, which have proven to be useful in such challenging situations.

Stay Positive and Confident

When faced with a project that forces you out of your comfort zone, it is especially important to remember to stay positive. The fear that stems from the unknown, especially in projects where it is hard to visualize the end result, is understandable. It is also natural to feel anxious in these fearful situations, but a project manager must be able to push all of this aside. Instead of catering to fear, the project manager needs to actively maintain a positive attitude that instills confidence in all the project stakeholders. If you believe it can be done, it will be done. Sometimes it is a matter of simply saying, “Yes, we will deliver the right solution.” Say it a few times and suddenly, the project seems easier to tackle.

Realign Client Expectations

Your first interaction with the client after the project has been signed off is absolutely critical. I always take this moment to realign the client’s expectations, especially in cases such as this where the risk is high, the budget is tight, and the schedule is strict. Although the client is dead-set on a certain solution, sometimes there are requirements that were not initially identified that need to be discussed. Likewise, sometimes there are requirements that need to be carefully reviewed to ensure that each one can be properly met. If I am up against requirements that just will not work, then this is the time in which I employ the art of compromise. From my experiences as a project manager, I believe that compromise is necessary in order to swim outside the box to find the buried treasure. Not only does it show the client that you understand what it is they need, but it also enforces the message that they are in good hands.

Research, Research, Research

A project of high-risk cannot be delivered successfully without doing a fair amount of research and development. To find a solution that would fit within the restricted budget and timeline, I needed to look beyond our internal resources and to third-party sources. Based on the client’s expectations and project requirements, I researched viable options and then was able to created informative documentation to present to the client. Not only did the presentation generate valuable feedback, but it allowed me to narrow my selection of 5 to 6 solutions down to 3 and 4. Although it does feel encouraging knowing that we are on track to finding “the one”, there is still that nagging feeling that I need to make the best decision, the one that will give the client a bigger bang for their buck. However, I remain positive that our understanding of the project’s requirements will allow us to make the most educated decision that will deliver a solution that generously exceeds the client’s expectations.

Keep Your Salesman Close

Last but not least, I make sure to keep my salesman – the one who approached the client with a solution in mind– as close as I can. As a project manager, it is important to do so for several reasons. If you cannot realign the expectations with the client during your first interaction, then it is time to call on your salesman to redefine the client’s expectations and project’s requirements. Likewise, if the solutions you have presented are not what the client wanted or expected, then it is necessary to call on that relationship between Sales and The Client to determine how to proceed. I trust that this relationship will encourage the client to compromise and accept a solution that I know will not only meet their needs, but I know that we can (and will) deliver.

The Next Step

Now that the client has narrowed the solutions down to 3 and 4, I am preparing to present a more detailed overview of these options to show how each one satisfies the project’s requirements. Because of the timeline and budget, soon I will need to go ahead and pull the trigger. In other words, I will need to make an informed decision to proceed with a third-party solution so we can begin the development process. Even though making this decision has proven difficult, I know that the worst is still not over; there is a timeline and budget that my team and I will need to be deeply considerate of until the very end.

Despite the fact that this particular project fell outside my comfort zone as a project manager, I welcomed the opportunity to learn and think more critically and creatively during the discovery process. Likewise, I appreciate the experience of this challenge, which I know will serve as valuable knowledge when similar projects fall under the umbrella of my management in the future. I have the utmost confidence that I am leading the client down the right path and that we will deliver the right solution on time and within budget, as promised.

Stayed tuned for Part II: The Challenges of the Development Process and Managing a Remote Team, in which Crissy discusses how “the one” solution was finally selected, how the team proceeded into the development phase, and how she handled the challenges of managing the project and its external resources, tight budget, and strict schedule.

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.

There seems to be a common problem in the Information Technology industry: it is a great challenge to deliver a web or software development project on time, on budget, and within scope. According to Advanced Project Portfolio Management and the PMO, only 16% of IT projects are able to achieve this status of official project success. We understand that a project must be managed well from beginning to end in order to go above and beyond a client’s expectations and to achieve this status of project success. In order to do this, we believe that you must set proper expectations, focus on project deliverables, communicate early and often, deliver within budget and timeline, and provide service-centered value.

Set Proper Expectations

Before you dive into any project headfirst, it is important to understand what exactly it is your client needs to achieve. After all, you would not build a house without first knowing how many rooms need to be built, where each room needs to sit, and so forth. A web or software development project is no different; it needs to have a detailed blueprint that outlines the end result at the very beginning. A project should not progress past its Discovery phase without completely understanding the end result and what steps will need to be taken to get there. Once it is determined how you will proceed from Point A to Point B, proper project expectations should be set that meet – but mostly exceed – the client’s needs. Likewise, a proper expectation should be realistic, uncompromising of requirements and deliverables, and courteous of a project’s timeline and budget.

Focus on Project Deliverables

Project expectations and deliverables are equally important and should be your focus of every project. When you focus your attention on the expectations of the project and its end result, it is much easier to understand how you will need to get from Point A to Point B. A project that lacks an end result in sight, however, is unlikely to be successful or survive the unexpected. Not only will focusing on the end result allow you to better understand the overall scope of the project and the tasks at hand, but it will also allow you to effectively manage these tasks and ensure that each one is proactively considerate of project scope and budget.

Communicate Early and Often

Communication is the key to exceeding a client’s expectations and delivering a successful end result. A project that lacks timely and routine communication faces the wrath of the unknown, which can be detrimental to the project’s timeline, budget, and end result. You should strive for consistent communication; this means scheduling a certain time and day every week to follow up with your client to discuss a project. This may include the discussion of the project’s status or any performance, testing, or development issues that may negatively impact the delivery of the project. By setting a specific block of time every week, communication allows you to effectively manage the project to ensure that 1) the project is on time, 2) the project is within budget, and 3) the project will deliver the expected end result.

Deliver within Budget and Timeline

To promote client satisfaction, you should aim to deliver an end result that not only saves his or hers time, but money as well. One way to ensure that a project is not exceeding its budget or timeline is to carefully manage change and unplanned activity. It is often said that in project management, the only constant is change. Therefore it is crucial to plan for these unforeseen circumstances during the discovery phase of the project. Change can be a budget and time killer, because it has the unfortunate potential to interrupt other projects and affect the availability of your resources. It is not an easy task to plan for the unknown, but it is extremely important to establish a budget and timeline that is robust, flexible, and accommodating to unplanned activity. This means determining the complexity of project deliverables, determining the greatest constraints (such as time, resources, et cetera), and then planning for these factors while being considerate of deadlines, budgets, and so forth.

Provide Service-Centered Value

At the heart of it all, a client’s expectations are indefinitely exceeded when you are able to provide service to them that not only satisfies, but surprises. We like to call this “Service Surprise”, which basically means that you strive to provide outstanding service that ends your client’s experience on a shockingly positive note. We want our clients to feel as though we are not only delivering an end result, but an end result that is coupled with service-centered value. Because every client is unique in his or her needs, the expectations we want to exceed will therefore be just as unique. To go above and beyond these needs, it is absolutely necessary to truly know your client and what it is they want to achieve. You should continue to manage the project beyond its delivery date by continuously thinking of ways that can provide more value to the client, such as analyzing the effectiveness of a user interface, revisiting a solution to determine if the workflow has improved processes, or keeping up-to-date with the latest technology threats and compliance standards.

We are able to go above and beyond our client’s expectations by abiding to our process and project management methodologies. Our process and project management methodologies ensure that we set proper expectations, focus on project deliverables, communicate early and often, and deliver within budget and timeline throughout the project’s lifecycle. Likewise, we distribute customer satisfaction surveys post-launch in order to obtain valuable information that allows us to improve service-centered value and our internal processes.

If you are stuck in that 84% that cannot deliver projects successfully or if your current processes or project management methodologies are preventing you from going above and beyond your client’s expectations, it might be the time to take a step back to analyze and restructure your framework to a way that will allow you to do so. We hope that these five tips are able to point you in the right direction to help you deliver your next project that achieves the status of project success.

Businesses love buzzwords. Many businesses will change their entire direction, sometimes against their better judgment, in an effort to attain the competitive edge the new “term” will give them. As quickly as trends come and go on the Internet, there simply is not enough time to research these new ideas thoroughly before implementing them. This leaves businesses not necessarily using the best practice or fully utilizing new concepts as they come down the pipes.

SEO (Search Engine Optimization) is one of these terms that has been spreading like wild fire. To compound the issues mentioned above, SEO is dictated by constantly evolving algorithms that are kept under lock and key by Search Engine companies.

Most people believe that the goal of SEO is to be “number one on Google.” This dogmatic mantra resonates through marketing meetings with cult like fervor. So much so that businesses are at times, losing site of the big picture.

The big picture is: the goal of your business. If your goal is to be number one on Google, then by all means, chant the mantra and go for it. However, most businesses are either offering a service or selling a product. With that in mind, while you are optimizing your site for search engines, make sure you are optimizing your site for customers.

It doesn’t do any good if you have a high rank on Google, but your website drives customers away in droves. Focus just as much on your site’s usability as well as its “findability.” SEO should be just one more tool in your marketing box, getting the same amount of attention as all of the others. An increase in traffic doesn’t equate to an increase in business. It simply increases the OPPORTUNITY to increase business.

While SEO is used in the context of being a magic bullet, know that it isn’t and use it for what it is originally intended and nothing more; and that’s simply making it easier for customers to find your site. The operative word here is “easier.” Not “the only” or the “best;” just easier. SEO, when working with other marketing initiatives will produce great results, but think of your marketing like a race car. When all the parts are functioning properly, the car will be able to stay competitive on the track. But regardless of how much work you put into the engine, your car won’t be going anywhere with flat tires.

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.

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.

Ok. You have decided to make a monumental decision: you are going to hire an architectural company to build a new house for you. After months and months and what has to equal hundreds of thousands of dollars, you drive to your new home, walk in and…realize things aren’t quite right. You flip the switch for the garbage disposal and the upstairs toilet flushes. When the dryer runs, the air temperature drops thirty degrees. This is not what you had in mind. You have wasted lots of time and lots of money on a product that, in the end, was nowhere near what you wanted.

This is a legitimate concern in the software engineering and development world as well as any other type of construction. It’s easy to just build a house or just design a car if a customer asks you to, but there is so much room for error and disappointment, cost in both time and money, that we choose a little more intimate of a route. Not only do we develop websites for our clients, but we also develop business systems. To do this in at our most efficient level, we go over the functional requirements of the system with the client and follow that up with use cases.

Some sites can be basic, flat html pages, where the user can visit multiple pages via links and learn about the company, the products the company sells, and navigate pages without really doing anything other than that navigation. For example, a florist shop – let’s call it Fiona’s Flowers, based out of Tampa – has a website with a few pages that give the company’s bio, some contact information, some pictures and a list of various plants and boutiques one can purchase at the shop. All in all, it’s not much more than an online Power Point presentation that the user navigates. One can’t buy anything online, nor can one compare prices to other companies when Fiona boasts that her prices are the best in the area.

Now let’s backtrack and say Fiona hasn’t had this business designed yet, much less a website, but she knows what she wants there. She comes to us and says, “Hey, I’m going to be building a floral company. I have nothing except my idea and how I want it to work.” It is then our job to define the functional requirements – what Fiona’s system has to do – for the business system and the company. She has to have customer’s able to purchase online, has to have a shipping service and options for shipping, has to be able to compare prices for each and every plant she sells with the competitive market, etc. We end up with a laundry list of the client’s desired functions for their system because we want to design a complete system for you. Software engineering is, in essence, no different than engineering a car; what are the pieces and parts I have to build to make all this happen?

We’ve listed what the customer wants and documented what this product should do, and now we have a laundry list for system purposes – the functional requirements. Once we have that, we lay it all out into modules, creating a model for everything from application to the storage database. After looking at this list and modules, each building block in the application model, we start creating use cases.

Let’s look at an insurance company, for example. One objective for a use case, the process associated with it, might be creating a quote and saving it to the database for future viewing. The functional requirements are the ability to print the quote, generate a pdf file for emailing, etc. A use case for this quote creation would documents the flow of a user’s steps to creating a quote, from interface appearance, generating a quote number, attributes of the policies available and coverage, and so on and so forth. The use case basically walks through the steps of how a user uses the web page of the insurance company and its components.

Also documented are the specific business rules applied. The customer enters information on the screen  and clicks “save.” The next step would be applying a business rule according to what is laid out in the use case – what has to happen. A quote number needs to be created. What numbers are generated? How are they generated? These are business rules that have to be applied to meet the functional requirements discussed earlier. What happens if the driver’s license isn’t validated or wrong information is entered? What happens if a license number has expired? These are logical business outcomes that need to be very clearly laid out. If a user wants to take a policy on Dodge Viper and the business isn’t willing or able to take on that car value, what is the process that needs to occur that sends a message of refusal? The response is documented in the use case.

---

We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone.

---

Use cases are important because it forces both our client and us to agree on everything that is going to happen. We get sign off on everything before we sit down and design the product. We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone. It’s not only a system for agreement, but it gives the developer, who doesn’t make much contact with the client until the use case is developed, a very specific idea of what they’re going to be building and how to go about doing it. As the blocks agreed upon in the functional requirements are built, what we had previously discussed and agreed upon is enforced.

So, back to the house example from the very beginning. If we built houses, we would sit down with you and discuss – and agree upon – the functions for everything in the house. This switch will turn on the garbage disposal, this will turn up the heat, and this will lock the door. There’s no room for confusion or the possibility of a devastating mistake either on your expectations or our construction. The whole purpose is to get confirmation that what we’re developing is in essence what you need before the product is created. It saves you money. It makes us efficient. And it makes the products stronger, better, and faster.