Showing posts with label communications. Show all posts
Showing posts with label communications. Show all posts

Sunday, August 9, 2015

Contracts Negotiations...

The recently proposed Iran agreement has created a significant amount of controversy. Much of the tone and rhetoric has been around the quality of the negotiations, and our ability to audit and enforce agreement compliance. Because of this, I’ve been reflecting on my personal experiences reviewing and negotiating information technology related contracts. My scenarios are significantly different.

There are no lives at risk. My involvement has primarily been with software, systems, and communications purchases. My first exposure was at an extremely well managed and efficient nationwide manufacturer. They were a family owned company that challenged everyone to continually improve, and operated in a very lean and efficient manner. This experience provided the base foundation for my own leadership journey.

The experience had taught me the following:

Negotiate from strength. The Vice President of Purchasing (Mike) always negotiated from strength. When Mike went in to purchase materials or equipment, he knew what he needed from the deal. He was ready to walk away if he didn’t achieve this goal. I’ve heard stories of people asking for his best price, and Mike responding with his number. When they countered the offer, he’d shock them by lowering his price instead of increasing it. That dance would continue until Mike received his terms, or he would walk away from the deal. It sounds like John Kerry never went in with this attitude, or the outcome could have been much different.

Be prepared to walk away. I was told of one instance in Mike's personal life where he visited a Cub Cadet dealer. Mike asked for the dealer’s best price, and apparently received it. He counter-offered a significantly lower price to start the game. The Cub Cadet salesperson went to his office and sat down at his desk. Mike assumed he was sharpening his pencil. The salesperson never came back outside, and Mike never went back in – both knew what they wanted, and were willing to walk away. If you’re too far apart on what your requirements, don’t be afraid to walk away. If Mike would have went back inside, or the salesperson came back outside, one or the other would have lost their leverage. Were our negotiators willing to use their strength and walk away?

 Set clear expectations. I met with Jim, the company's Executive Vice President to discuss the contract for a large ERP software purchase we were negotiating. We worked closely together with Mike to negotiate the price and terms for all technology purchases. Jim related an experience he had as an executive at a smaller airline. As he was reviewing a purchase of a multi-million dollar jet, and reading the terms and conditions, he made an odd discovery. He realized the aircraft he was purchasing wasn’t guaranteed to fly. He had done his best to improve the terms and conditions. However, this was only effective up to the point where the vendor was willing to walk away. In some cases, there was little he could do since he wasn’t negotiating from a place of power. He needed the airplane to fly passengers and generate revenue. In other situations, he was negotiating from a place of power, and was able to obtain significantly better agreements. The key, he said, was mitigating risk to an acceptable level… understanding what’s critical… and recognizing your leverage. Enter your negotiations process knowing your bottom line price for the level of service you require, each partners responsibilities, and what risks need mitigated before you can accept the agreement. Did our country do this with the treaty?

Communicate clearly, and get contract clarification in writing. Ambiguous language should not exist in a contract. If there’s something you don’t understand, or that is subject to interpretation… get a concise explanation that both you and your vendor can interpret clearly included as a signed addendum. The tale about the buyer at an auction asking what to do via text when the equipment he wanted was higher than he was authorized to spend is an appropriate example. The authorization he received included “no price too much”, so he kept bidding until he won the auction. Unfortunately, so the story goes… what should have been communicated was “no, price too much” – a very different message. The company ended up going bankrupt because the added equipment expense damaged their ability to continue operations profitably. Make sure you’re communications, interpretations, and understanding with the vendor are mutual and concise. Explicit contracts that clearly outline the contract requirements do not signal mistrust, and are NOT counter to a successful vendor relationships. Quite to the contrary - they reduce misinterpretations, build trust, and become the foundation for a mutually beneficial and profitable partnership.

Recognize risk and scope appropriately. Read the terms and conditions. Open source software licenses do not require monetary payment. However, some do require any vendor that incorporates this code into their product to also make it freely available under the open source license. This isn’t a good option for a vendor that markets software and makes their money by selling software solutions. Work with your leadership to identify parameters for acceptable risk, and understand these limits. There is a different level of risk purchasing a copy of Microsoft Office vs. negotiating an enterprise software agreement. Did our leadership recognize the risk and scope for the Iran deal?

Be fair, and partner for success. Your goal with contract negotiations is to create a fair and explicit agreement for all parties involved. There is no success in driving a critical supplier into bankruptcy. This agreement is the basis for a collaborative partnership. There may be times where you may need something expedited, and you'll need goodwill to help get things done that may be outside the scope of the agreement. If every agreement is one-sided, you'll damage any potential relationships, and that won't help your organization in the long run. If you want customer loyalty, then you must have some level of commitment with developing and establishing relationships with your key vendors. 

Differentiate between critical and non-mission critical agreements. Know what's critical and important for your organization. Based on your industry, the importance of a paper contract could be quite different. Treat each type of agreement appropriately. If you negotiate a paper contract for a widget manufacturer, these are likely considered expenses and probably not part of your core business unless they are required for packaging. The level of diligence may not be as important as ensuring that purchases of widget raw materials meets your requirements and is delivered on time. However, paper would be critical if you're in an industry that requires these as a raw material to deliver goods and services, such as a newspaper printer.

Be explicit with context. I have one final thought on clarity in communications. Be specific and explicit in negotiations, and ensure you have spelled out the CONTEXT for each of the critical points. Do not assume context, or your contracts will be subject to misinterpretation and miscommunication.

 I thought I’d share some of the my thoughts on contracts review and negotiations. So, don’t be afraid to work hard and get your hands dirty. Always take the time to climb up to the top of the mountain, reflect, and look out on the horizon to survey the landscape. From the mountain top, we can get perspective on our progress, identify threats and opportunities, adjust our processes and direction, and be proactive. Go climb your mountain, survey your landscape, and adjust as appropriate. This journey is easier if you find a great mentor - mine was "Jim". Go find your "Jim"!

 I hope you enjoyed reading this as much as I enjoyed writing this entry.

Friday, July 31, 2015

Right-size Processes To Add Value

I've been in a few conversations recently about "overhead' processes, and my favorite topic - adding value.  I'm going to provide a few examples of what I consider rightsizing processes.  These processes should be implemented judiciously and appropriately to deliver the information and results needed to add value and deliver your projects on time.

Often excess processes can significantly reduce productivity, and staff become complacent and don't believe the work they are doing is important.  Keep your team energized by being a leader and establishing processes that are appropriate, effective, and add value.  Some broad examples of rightsizing are below:
  1. Project Management - I cannot stress the importance of tracking projects at an appropriate level to create a critical path for developing and managing the timeline.  My experience is that this is as much of an art as a science.  The science is in the methodology, the art is in the understanding and ability to identify dependencies and timing accurately.
  2. Time tracking - I've posted about this previously.  Track sufficient information using appropriate granularity to support your project schedules, accounting for resource time in a broad sense by service and category.  Right size this so you do not expend valuable project and service resources recording unnecessary information.  Tracking information that is not useful for improving project management, increasing support for the service, or fulfilling sponsor reporting requirements is frustrating for staff  and wastes precious resources.
  3. Disaster Recovery / Business Continuity Planning - Nobody ever expects a disaster to occur. However, they do... and it is too late when you realize that the one person with the knowledge to recover your enterprise service just took off in a plane destined for a remote village half-way around the world. 
  4. Cross Training -  Cross train your staff, and document basic operational requirements.  They may complain about the additional work.  However, when they discover that this enables them to take vacations without being tethered to a work device, they will thank you.
  5. Change Management - Do an appropriate level of planning and documentation of changes, and incorporate this into your processes to support audit requirements and aid in identification of  causal effects.  Manage change so that risk is minimized, and recovery from change can be reverted without a significant amount of effort.
  6. Incident Reports - these are extremely helpful in developing an understanding of impact, and causal effects when something significant goes awry.  Reflection and openness are necessary to change processes and mitigate future risk.  Again, do not spend five days documenting an incident that was minor - and that only merits minimal documentation of the issue, impacts, and lessons learned to help reduce future risk and improve recovery.  There are times when risks must be accepted, and that's okay as long as the risk and potential impact has been mitigated to an acceptable level.  Our greatest failures can provide the best learning opportunities.
  7. Meetings - maximize efficiency by preparing for the meeting, and having a clear agenda.  Document follow-up items, delivery dates, and ownership.  Not preparing leads to wasted time.  Having nine people wait for ten minutes for the tenth person wastes 90 minute of productivity that cannot be recovered.  Preparation should be appropriate for the topic and audience.
  8. Communications - Appropriate levels of communications are critical.  Too little communication, and your stakeholders are uninformed and can become unpleasantly surprised. Too much communication and your messages are ignored.  Work with your stakeholders and staff to establish a level of communications that is appropriate.
The most important part of this is collaborate with your team and stakeholders to define a level of process that is consistent and appropriate.  Be inclusive and transparent in the discussion, accepting and acknowledging feedback to develop processes that improve overall efficiency.  Most importantly, evolve your processes to continually become more efficient.  Perfection is often something we cannot afford in our lives.  The sooner we acknowledge this, the more efficient and effective we become.  Be a good steward of your resources, and strive for customer satisfaction and good stewardship.  If your services are not affordable, you will not be in business or servicing your customers for any length of time.

That's it for this post... until next time... lead and manage for success!

Sunday, January 12, 2014

On Transparency & Openness: Buzzwords, or Reality?

I've been doing some contemplation on what it means to be transparent and open.  New Jersey's Governer Chris Christy, love him or hate him, is airing some dirty laundry over a bridge closing orchestrated by his staff to punish a mayor that didn't support his campaign.  Will he be open?... and is he being transparent and honest?... are you with your customers?  Ouch... there's that mirror for reflection and introspection again!  I haven't watched the entire two hours of his recent interview... however... based on some highlights... he accepted responsibility, he was apologetic, and he was humbled, which is pretty amazing for an outspoken person.  Humility, honesty, and ownership are good traits to help you succeed, and gain the respect of your peers.

Dealing with customers requires the same type of communications.

  1. When planning a project, share details and be transparent.  However, don't allow your project to be micromanaged by your customer (collaborate and compromise, however - recognize you are the domain expert for the technology).
  2. There are times when you need to make hard decisions, and there is a customer impact.  Don't make short-sighted decisions... know the difference between when you MUST impact your customer to protect them from an immediate threat or imminent failure vs. when you can work around their needs and requirements.
  3. When something occurs that impacts your customers, then be transparent.  It doesn't necessarily mean kicking ass and taking names... pointing fingers... or throwing the Junior Programmer under the bus for a first time mistake.  It's accepting responsibility for the team, and providing detailed follow-up that includes details on the incident (a.k.a. and incident report).  
  4. The report should detail the basics...
    1. Who - was impacted?
    2. What - was the impact to your customers?
    3. When - was the impact, and the timeline for service restoration?
    4. Where - which locations / populations were affected?
    5. Why - did this happen?
    6. How - did your recover, and how are you going to prevent this from recurring in the future?
  5. Look for opportunities to improve your processes and prevent future failures from occurring for the similar circumstances (called Lessons Learned).  This can include process changes, additional testing, monitoring, or other improvements that could reduce the likelihood of happening, or improve the response time for recovery.
  6. If you have internal issues to address, then address them objectively with education, employee development, policy, and process.  Communicate this to your customers, remember that sometimes even measured and mitigated risk still result in a failure or process breakdown.  Mitigated doesn't mean eliminated.
  7. There are times when you may need to take personnel actions... and when you do... for the respect of the individual, team, and yourself... follow policy, be discreet, and where possible, look at it as a learning opportunity.  If there are too many learning opportunities... maybe you've not properly mitigating risk, have policy problems, or quite possibly, you may not have hired the right person for the position.
A number of years ago, when I directed IT for JennMar Corporation, one of my developers released a bug that was pretty visible to our executives.  One of the executives called me, he was looking for someone to "ream out, take names, and kick ass".  My response was... go ahead... it's my department, so regardless of who made the mistake, I'd handle it internally.  If they needed a name to blame, it was ultimately my name... my department... my responsibility.

I handled the issue internally, it was a learning opportunity for a solid developer, and my response gained respect from the executive... since it demonstrated a sense of departmental ownership.  It also gained respect from the developer, since he worked for someone that didn't take his credit and pass blame.  (Yeah, I hate to see those people in any organization too!)  Give credit where credit is due, take responsibility for properly mitigated risk (not the same as a blatant disregard for rules - that's a train wreck), and work to continually develop your team... and... get their feedback so you can continue to improve your skills as well.