KICKBACKS: A How-To Guide and Expectations

PURPOSE OF THIS DOCUMENT:

The purpose of this document is to serve as a guide for writing a kickback. Kickbacks are important
because they are the communication that we have between division resources and development when a
problem arises in the design tools.

The role of a division resource in the kickback process is to not only determine that there is a problem,
but to perform the necessary investigation required to solve the problem. To properly do so, the
following should be followed. THE RESPONSIBILITY OF THE DIVISION RESOURCE FOR KICKBACK
DOCUMENTATION IS NOT LIMITED TO THIS DOCUMENT. IT SERVES ONLY AS A GUIDE. Similarly to
designing buildings, one must sometimes use proper judgement in determining necessary information.

STEP 1: Determining if your issue is in fact a bug and finding a solution.

It is vital to get to the point where you can do this without the aid of the design tools leadership team.
You can do this by answering “Who, Where, What, When, How, and Why.”

When the tool is not working properly, it can be frustrating and nonsensical. However, there are many
reasons that the tool could be not functioning properly, and therefore the user should ALWAYS FIRST
ASSUME THAT A “BUG” IS DUE TO USER/LOCAL ERROR. It is easy to pass off the issue back to
development and “wash your hands” of the problem because it doesn’t make sense. However, as stated
before, it is the job of the division resource to thoroughly investigate and determine potential solutions
to the problem.

In order to determine if you have a legitimate bug, you can perform/answer the following:

 Are others seeing the same bug (Who)? What is happening? Consult other teammates before
the leadership team. Do NOT send out a massive email asking for help. Be direct in asking
someone for assistance. Have a reason for picking a teammate to look into an issue. Possible
reasons for choosing a specific teammate:
o You are new to the design tools and would like a person who is experienced to ensure
your process is correct.
o That teammate has a specific knowledge or greater understanding in what you are
testing (could be design specific or perhaps the teammate worked on this task before)
o You would like to verify that the brand specific information is correct
o You work well with this person and would like to think out loud about it for a few
minutes
 How/when did this start happening? In order to determine this, it may take some time to figure
out what caused the problem. Some questions to answer during this investigation could be:
o Is it a cost model problem? Did it happen in previous Cost Models?
o Does the current production version of the tool have this problem?
o Was there a large change that occurred recently that could have sparked the problem
inadvertently?
 KICKBACKS: A How-To Guide and Expectations
 Can you re-create the problem? Are you able to provide information that is the expected
outcome? This is probably the most crucial question to ask as you are testing. Before you can
report your bug/kickback, you must be able to recreate the problem in a few different ways. In
order to do this you have to pinpoint WHY this is happening. There could be a million different
reasons for it, but here are a few places to investigate (Where):
o Certain geometry elements are causing it
 Roof slope
 Bay spacing
 Width/length/height
o Certain design loads are causing it
 Seismic/wind/snow/live/notional loads
 Added concentrated loads
 Specific design codes
o Other parts of the tool are causing the issue
 Is it incorrect in a different place?
 Is the UI correct?
 Does the report match the graphic?

Again, this is just a sample of what is required to investigate a kickback. Some are simpler than others.
Getting to the point of being able to investigations without the help of the design team is very
important. HOWEVER, there will be times that you need guidance from the leadership team. It is
important to do your due diligence as a division resource before raising a red flag and causing
unnecessary havoc.

STEP 2: Determining the Solution

After you have identified Who, Where, Why, When, What, and How, you must come up with potential
solutions to your problem. This portion can be tricky. You must use all of your investigations to do this,
and you may come up with more than one. It is recommended that you give a single solution you think is
best, but you can also include other items as well. Coming up with a solution will answer these
questions:

 What needs to happen next?

 Who needs to do what?
 What is the outcome that is expected or desired?

After getting all of you investigations together, and you have come up with a solution(s), you can now
relay this information to development.

STEP 3: Creating the kickback document.

 KICKBACKS: A How-To Guide and Expectations
After determining everything you need to know about your problem, it is time to document it so that it
can be used by a developer to fix the problem. KEEP IN MIND: developers are not engineers(!!) (at least
most of them), and they need you to be very specific.

Using the kickback template on the gs1 server, the outline of this document should go something like
this (keep in mind that this may vary to be more or less extensive case to case):

1. Summary of the problem found and possible reason(s) you believe it is happening.
2. Example(s) of the issue. Items to include here:
a. What versions/cost models were checked (should be in the header of the kickback
template)
b. Necessary screen shots of the problem CLEARLY outlining what the issue is.
c. Comparison for what the desired outcome should be
d. Why you think it is happening
3. Conclusion that gives proper direction to the developers for fixing the issue.

YOUR WRITE UP SHOULD CLEARLY ANSWER “WHO, WHAT, WHERE, WHEN, HOW, AND WHY”. This will
help the developer have a better understanding of the problem at hand.

STEP 4: Send for review/distribution

After the document is completed, it is recommended that you send it to anyone you have worked with
on the issue to briefly review the contents so that they can give any constructive feedback.

After the document is reviewed, is must be sent to the following people: Division Resource Group,
Jennifer Case, Robert Dennis, Alexsys Smith, Bob Smola, and Brian Hills. Your email should include the
following:

1. The person(s) you worked with on the kickback

2. A brief summary of what the bug is
3. The PBI(s) that are affected by these problems
4. Attach your document AND the example files used to find the problem. Outside of actual design
tool files, this could include XML documents (eQuote and MBS), Configuration Files, Purchase
Orders, SMaths or Spreadsheets for reference, etc.

STEP 5: Follow up/Follow Through

The final step is to be sure you pay attention to your kickback and be sure that it was received. We all
share ownership of our work and just because you have passed it on, it does not exempt you from
responsibility. Be sure that the following happens:

 You receive an email from the design tool leadership that a kickback task/red tag has been
created.
 The kickback is documented in the kickback log on the gs1 server.
 Be available to answer questions from the design tool leadership team or a developer.
 KICKBACKS: A How-To Guide and Expectations
 If you don’t hear back for several days on the topic, to just ask about what happened with the
item. The design tool leadership team will do their best to relay any information or decisions
made on the topic.

Last but NOT least, there are items that are considered “wants” versus “needs.” As division resources we
can have a difficult time determining between the two. A “want” is an added functionality that is not
crucial to the success of the program. A “need” is a direct error that does not allow the user to properly
design a building using the tool. You are welcome to express “wants” as McPir items, or, even better,
with your design supervisor.