Teacher pointing to chalkboard

If you are familiar with professional service companies specializing in Web Development or Digital Applications, then you are undoubtedly aware of the pressures and day-to-day struggles that come with meeting the demands of clients. Contrary to social folklore, the customer is not ALWAYS right, however they should always be HEARD. Instead of arguing and potentially losing a client, here are some helpful actions meant to prevent you or your company from constantly battling over the same ground.

The basis for these guidelines is Education. Educating your clients isn’t difficult, however it is an essential part of any successful project and following these guidelines can certainly improve the working relationship you have with clients. It is very important to note: this Education needs to take place before the project begins and even before pen touches paper. Trying to implement these recommendations after work has begun is asking for serious trouble.


Setting a solid foundation for a new project means forging reasonable/attainable expectations with your client. Promising too much or too little is easy to do. It is imperative that you make your presence and views on important topics known from the start. The client needs to know and more importantly understand that hiccups can and will occur causing inevitable delay or push back of other requests. Of course, you and your team do your best to minimize these mishaps, but we are all human and software is challenging! Setting these expectations with the client ties heavily into the next key point.

People communicating via headset and computer with speech bubbles


Before you get red-faced, I’m not implying you talk with the client daily and in turn get loads of requests and feedback while not getting any actual work done. Communication in this sense refers to meetings or demos you set up and speaking to the client ensuring they know that feedback needs to be thorough with explicit details on what they require. The C-word also refers to you as the designer/developer reaching out for questions and concerns along the way. There is no need to wait until interim meetings when something pressing is hindering you from delivering the highest quality product.

Man presenting to a group of people


Sometimes this is the most difficult guideline to handle with finesse. You are trained, certified, college educated, and/or have designed and developed for years; one or more of these things qualify you to do your job and do it well. Clients have opinions and some are much more vocal about them than others. Establishing your credibility is fundamental in getting the client to understand you are not injecting your personal styles for the sake of it. A few ways to soften the edges and effectively guide them is to show some solid research or data that backs up your decisions, or give examples of other sites or books that use your design and function well. Also, when demoing to a client, don’t just click through the process, take time to explain in detail WHY you did these things.


Nothing is worse than hearing “I just don’t like that”, or “Could you try something different?”. Educating the client and nicely pressing them to continually provide meaningful input until the project is complete is highly beneficial for both parties. It is vital to take the time at the beginning of a project to really listen (and ask questions) about what the client is looking for in a website which in turn could help circumvent the need to teach this lesson at all.

Two men in suits shaking hands


The main reason a document outlining the work to be completed and the terms in which they are handled is drafted and signed is to protect both parties. Sounds simple enough, but often work is shoved in to a workload that was never discussed during contractual meetings. Without question there are exceptions and new items that arise during a lengthy project but be sure to stand firm on variations from the agreed upon terms. Reading the contract out loud to the client and conversing about all questions/concerns is a necessary practice in establishing a firm base for success. Some key things to highlight in your detailed contract should be:

  • Intended work hours
  • Milestones/Phases for the Project
  • Payment rules
  • Requirements for Feedback
  • Overall budget with overtime costs

It can be a wonderfully pleasant task to create a beautiful website for a new or established company. Everyone can be on the same page and the budget can be effortlessly adhered to and the client can receive everything they wanted. For the imperfect scenario (basically 99.999% of them), you can follow these 5 guidelines to hopefully prevent World War III. Educating the customer has been and always will be the smartest way to provide effective and fruitful client services throughout any project.

The Agile development methodology was formalized in 2001 and has become the leading process for software creation. Developers love the flexibility it gives by not requiring that everything be figured out up-front. But as a client, how can you feel comfortable signing a contract without already knowing exactly what you will get?

First some background

Classic software development involves a sequential process:

  • Requirements – define the problem and solution in complete detail.
  • Design – create the blueprint to implement the requirements.
  • Construction – build the system based on the design.
  • Testing – confirm what was built works as specified in the requirements.
  • Implementation – launch!

This process is commonly referred to as “waterfall” because the output of each phase flows into the next.

Waterfall Software Development Lifecycle diagram

At first glance this seems like a very reasonable approach. The requirements represent a complete description of the work that will be provided, and serve as the contract between the client and the development company. Expectations are clear and both parties are on the same page.

Why wouldn’t we always want to do that?

The problem is that software is intangible and complex. Words on a page don’t always capture and communicate the essence of what is desired. Even a very clearly stated requirement can be interpreted and built 100 different ways, and it is likely that at least 95 of those won’t be satisfactory. The result is a well-repeated (though somewhat mythical) response from the client:

It’s just what I asked for…. But not what I wanted.

How is Agile different?

Agile was created to address shortcomings in the waterfall process that occur when developing a complex software system.

The principle difference with Agile is that it is a very iterative and interactive process. Agile projects are broken down into short mini-phases called “sprints” – At Mercury our sprints are 2 weeks. The entire requirement-design-construct-test-deploy cycle happens within each sprint. The goal is to have demonstrable results to review with our clients every sprint and get feedback.

Agile software development lifecycle illustration

Imagine with the waterfall process if a fundamental assumption was made during requirements, but during testing was proven to be false. The project is nearly complete and potentially months of work must be revisited. By doing small incremental feature development, we prove out our assumptions quickly and can change direction as needed.

Change Happens!

Change is the enemy of the waterfall project. Imagine we are building you a web application, and 80% through construction an event occurs in your business that suggests changing course would be beneficial. By now you can see the devastation this brings to the project. This ends with a difficult conversation on change requests and costs.

OK I get it… so what’s the answer?

First let me put you at ease, because by now you may be thinking where I am headed is to ask for a blank check with no understanding of where we are going.

With Agile you still need a vision. At the beginning of the project we need clear understanding of some high-level questions:

  • What problem are we trying to solve?
  • What goals do you want to achieve?
  • What approach will we use to solve your problem?
  • How will we define success?

With this framework, Mercury can define a solution by creating a set of “user stories” which describe in your language both the functionality desired and the benefit. Here is an example story related to workflow in a hypothetical cash disbursement system.

As an Employee Supervisor
I want to review pending disbursements and approve or deny them
So that I can confirm their accuracy prior to generating payment.

This statement tells us not only what you want to accomplish, but who cares about it and why. What we don’t do is try to define every single field, button, and click in the process at this point – we don’t know enough yet. Doing so is frankly a waste of your money because it is almost guaranteed to require revisiting later when we do know more.

We then take this collection of stories and estimate time and effort, which of course translates into dollars. With your approval, we will begin work towards meeting your goals with a budget to work against.

Every two weeks we review our plan and select the features that will provide you with the most value that can be delivered in the next two weeks. When complete, we demonstrate these features, get feedback from you, and then plan for the next sprint.

Agile Scrum Board

The key advantage agile provides us is the ability to course correct after every sprint. Once we start delivering features you can see and touch, you can quickly see where we are headed. This gives us the opportunity to adjust as we go, instead of getting to the end and realizing we are in the wrong place.

It’s all about value!

Agile also gives you – the client – control over the process. If you want to add something new, we can do that! If you want to do that but not change the budget, you get to pick what we take out. Or maybe the new idea adds so much value you are willing to add it on top, but you get to decide.

You also have the option of eliminating features as we make progress. Maybe you thought we needed to build out some reports, but now that you are seeing the lookup screen come together you realize they won’t be needed. The good news is since those were prioritized lower, we haven’t spent any time (i.e. your money) on those features yet, and you can easily cut them from the project.

Project completion

When we get to the end of this process we may end up with something that looks quite different from what we originally envisioned. Ideas were revised and features were cut in favor of others that were added. But by focusing on the overall goals of the project instead of rigidly holding to a narrowly defined requirements document, we will end up with a superior product that was created collaboratively and truly provides the value you wanted.