CAD Management: Agreements

November 27th, 2010

CAD Managers are always making agreements - formal and informal. They agree to perform functions or get others to agree to work in a specific manner with the guidelines they produce. They make agreements all the time, BIG and small.

Getting someone else to agree upon a course of action is not always easy. It often takes time and a lot of talk. Resolution is based on shared information. Conflict is based on the withholding of information. If you are committed to gaining agreement, you must be committed to sharing openly what you seek to gain and what is needed to get there. You must talk and you must listen.

There are some simple agreement concepts that may or may not be spoken. You need to let everyone know what your perspective is and also be willing to listen to theirs. What each side wants to achieve may differ.

Here is what most agreements are made of and what needs to be included:

  • Agreements describe the big picture of what you are trying to achieve. If you just talk at the task level, then everyone will see only the individual tasks that you think need to be done. Then they must decide if they will agree to do them. If you paint on a larger canvas the overall end game, then you may get more buy in on the individual tasks that initally seem to others to be unnecessary.
  • Detail your goals. Give enough substance to your target so that others can see where you are going. Giving a team a single puzzle piece without allowing them to see the finished picture on the box can cause much frustration.
  • Spell out the duties and roles of every team member, even if it is just two people. Everyone needs to know what they must do and what their roles are in the overall picture.
  • Be specific about the milestones. What does each person need to get done and when does it need to be completed? A list of deliverables and when they are expected will smooth out any confusion related to what you might want, who will do it and when it needs to get done. If needed put a due date and time on everything.
  • Define deliverables. Make sure that all parties get what they think they are getting. Kind of like the deliverables above, make sure that each person knows what they are going to get out of the process.
  • Define success. Make sure you provide some metric for measuring success. It may be met deadlines or production output or whatever. Just make sure that all parties know when success has been achieved (or missed).
  • Define course correction processes. Nothing goes as planned. Define who can call a time out or change the game plan. Not everyone can be a decider. The roles that each person plays define their ability to stop the production run. If you allow every person to stop production, make sure that is spelled out. If only one person can, then make sure all know who that is and understand the appeals process.
  • Allow people to back out gracefully. If someone is not able to participate as they thought they would, make sure that they have a graceful way of notifying everyone before it becomes a critical path issue.
  • Define the impact of a broken promises. If someone slips a due date – what happens? If someone does not follow procedures – what happens? If left undefined, then no one will know feel the impact of a failed effort before it takes down the whole process.

Keep it simple
Covering every item I mentioned above is not done all the time. Big agreements need more attention; smaller ones can often function on the fly. Make it only as expansive as it needs to be. If you only cover three or four of the nine that I mentioned that might be fine. Covering them all at some level may be needed with some teams or goals. Define them as detailed as they need to be for the level of effort you expend on the task. Obviously any kind of legal agreement or contract will go beyond the ones I have outlined and include many more things.

But do not underestimate the value of talking out even simple agreements to the point where everyone understand who does what by when. It will avoid headaches later.

Join AUGI Today

Become part of the largest Autodesk community

About the Authors

Mark Kiker

Mark Kiker has more than 25 years of hands-on experience with technology. He is fully versed in every area of management from deployment planning, installation, and configuration to training and strategic planning.  As an internationally known speaker and writer, he is a returning speaker at Autodesk University since 1996.Mark is currently serving as Director of IT for SIATech, a non-profit public charter high school focused on dropout recovery. He maintains two blog sites, www.caddmanager.com and www.bimmanager.com.

 

Appears in these Categories

Appears in these HotNews Issues