Categories
Change Management Engagement Management Software Development

So, You Want What?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Communication with Vision Variance

The swing picture has been circulating for years and we all still laugh at this picture, because it is still so true. Everyone who works on projects can relate to it. Yet if we know this happens, why is it so difficult to make a change?

English: The Universal Language

The customer speaks English. I write in English. Developers read English. Where is the confusion? What is the problem? Well, still the widget is not doing what is needed. This is because it is easy to believe everything is clear, yet there is still misunderstanding. Take for example the following statements:

1. “We need to produce a Minimally Viable Product(MVP).”

  • The application functions?
  • Oh, you want user tracking and analytics too?
  • You need email marketing automated?

Minimal needs clarification. If something is required, state it as required. On some projects I have provided a raking from Required to Nice to have.

2. “We have doubled our impressions”

  • Twice as many people are thinking highly of us?
  • Twice as many people are visiting our site?
  • Twice as many people saw our ad?
  • Our advertising is working?

English terminology can be different. Depending on the audience, clarification of terms and what they mean, or do not mean, could be useful.

3. “Take it EZ. “

  • Do not worry about it?
  • Only put in 4 hours of work today?
  • Do not work past 9 PM?
  • Sit around and watch TV?

People have preconceived ideas about what this means.

4. “There is no hurry on that”

  • Whenever I get to it is fine?
  • You need it today, but not right now?
  • You need it in the next hour, but not the next minute?

Without clarity on this one you could really get you into some trouble.

5. “What are possible solutions?”

  • Option A
  • Option B
  • Option C

Boss, “I like Options B.”

Contractor, “That one is not in scope. We can price that option for you.”

Boss, “Which possible solutions are in scope?”

Contractor, “Option A”

Here the contractor could stand to clarify the options as to what will add cost to the project.

The above examples point out how easy it is to state something clearly as we can all read what was written, but there can still be miscommunication.

Spending Less is Better!
(Or Maybe Not?)

A 2019 BMW Z4 is selling for $72,000. However, on the other side of town you can get the “exact same car” (color, model, features, etc…) from a different dealer for $65,000. Spending less is better.

It is the same with software. Spending less for the same thing is better. If you are looking at a finished product, such as Turbo Tax for Business, and you can pick up a copy for $99 or the same product at another store for $89, spending less is better.

Imagine a scenario where Company X has put together a document describing their widget requirements and asked for quotes from three different software companies. The three different companies all supply their price to deliver the widget. They tell Company X what they will charge for the work. Should Company X award their contract to the low bidder? Is spending less better?

The Lowest Cost Was More!

Think about the swing picture which everyone laughs about. Which block of the picture was being described by the requirements? Which block of the picture was estimated by each of the software companies? There may be three costs provided, but what they plan on providing may not match the widget Company X has in mind.

You can sit in a room with employees of Company X, discuss what is needed, and still everyone walks away with a slightly different picture or understanding of what is needed and how best to proceed. We have the meeting to clarify details and reach consensus, but there will still be variation. What is the variation and how important is the variation?

“I know that you believe that you understood what you think I said, but I am not sure that you realize that what you heard is not what I meant.” – Erik Jul

One meeting attendee may think the system is getting a blue widget. Another attendee may think the system is getting a round widget. It may be the case that being blue or round is not important to Company X, but the functionality of the widget is important.

Projects proceed with some balance between clarity and ambiguity. It is important to understand this and identify prior to the start what balance is needed. How complex is the widget? How much detail is needed regarding the widget?

  • Higher Complexity = Higher Cost
  • Higher Detail = Higher Cost

Specifications around the widget, what is being bought, is a balance between clarity and ambiguity. When a project is starting it is important to have an understanding that there is a level of clarity which is needed and a level of ambiguity which is tolerable. Change in a project is inevitable. However, change has a cost.

What if the software company with the lowest bid makes a blue colored round widget, but does not get the functionality correct? Because the needed functionality is not present, a change is required. Changes cost money. This cost is both the cost to make the change in functionality and the loss due to the widget not being available. It is quite possible that the cost of the change now makes the company with the lowest bid the highest cost.

There are other considerations as well such as how something is built, future maintenance, ease of adding functionality. The lowest cost at first glance, does not mean it is always the best choice

Ways to Add Clarity
(A.K.A. Best Practices, Recommendations, Things to Try, Solutions)

1. Visible to All

There is a cost to both clarity and ambiguity. Documentation which can clarify a widget takes time and effort which has a cost. A lack of documentation which adds ambiguity around a widget adds to the possibility that rework and change will be needed before the widget is completed. I recommend the Rapid JAD principle of Visible to All as a model for gathering data about a widget and adding clarity. This can include pictures, diagrams, and flows. Imagine if the customer had provided a picture of the swing they wanted.

2. Six Components of a Well Written Requirement

Often requirements which are developed are missing information which helps add clarity. In my blog The Magic 6 I list the six components which should be a part of every requirement.

3. Test First

Whenever possible, provide the test(s) for successful completion of the widget along with the requirement detailing the widget. Providing the test(s) adds clarity to what the widget must do. For example, the swing may have weight requirements. Specify that you will be testing it with 150 pounds of weight.

4. Dictionary of terms

Different companies use terminology differently. This can lead to confusion. If there are terms you know are used in a specific way in the company, define them. I was in a meeting and the presenter was using the term, “Impressions.” I was wondering if the audience knew the definition of an impression. If they did, perhaps they would not have been as impressed.

Summary

Projects can have a lot of additional costs. For high cost projects or projects which are business critical, I always recommend looking at the past experience of the leaders who will be running the project on a day to day basis. They will know what to look for to balance clarity with ambiguity and make sure clarity is pulled in where there is currently ambiguity. Experience will help get you the needed widget in a timely fashion. After all, if what you need is a tire swing, but it costs you like a La-Z-Boy recliner or takes as long as a coaster, someone may be looking for the noose.

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail

By Greg Swearingen

Greg Swearingen’s been designing and building business applications for over 19 years and providing training for over 28. Applying his skill from the early days of Netscape Navigator to today's mobile environment he stays up on the best of the best. While having designed and developed numerous software systems over the years, he is most proud of the award received for software developed and used to help those deployed during Operating Iraqi Freedom and Operation Enduring Freedom. Greg continues to develop, train, and he tweets @gergnotes.