Looking for something? Look here!
Want more unvarnished truth?
What you're saying...
What I'm saying now
I think tag clouds are pretty, and not to be taken overly seriously
##MoveWithGary #Home Inspection #MoveWithGary 111 Chop House 75 on Liberty Wharf 9/11 A Broth of a Boy ABCs Abiouness accountability activities alcohol Allora Ristorante Analysis Angry Hams ANSI/TIA 942 Anthony's Pier 4 Apple Application Armsby Abbey Arsenal Arturo's Ristorante Ashland AT&T Audio Automation baby Baby Monitor babysitting Back To School Bad News Bangkok Thai banks lending movewithgary Bar Bay State Common baystateparent BBQ BCP Bees BeeZers Before I die I want to... behavior Big Bang Bike Bill of Rights Bistro Black Box BlackBerry Boston Boston Marathon boundaries Boyston BPO brand Breakfast Bridge Bring Your Own Technology Budget Burlington Burn Burrito buyer BYOD Cabling Cambridge Camp Campaign career Casey's Diner Castle casual cCabling Cell Phone Central Square Change Management Cheers Chef Sun ChengDu Chet's Diner Children Chinese Christmas Christmas Families Holiday CIO Cloud coddle collage College College Acceptance co-lo Co-Location Co-Location Tier Power Cooling Comfort Food Control Country Country Kettle Crisis customer dad Dad Phrases damage daredevil Data Center Data Center Design Davios Day Care Dead Death declaration Del Frisco's Design Desktop Video dinner Disaster Recovery Divorce Do Epic Shit dodgeball Downtown Crossing DR driving Droid Easter Economic Kids Edaville Education Elbow Night Elevator Employee Engagement Erin Estate Planning Etiquette Evaluation events Exchange Expiration Dates Facebook Failing family Family Law Fatherhood Favorite things first time buyer Flash Flemings Fogo de Chão Food Hits and Misses Format Foundry on Elm Foxborough Frameworks fraternity Fraud French Fried Clams friends fun Fusion Generations germs Girl Scouts girls Global Go/No Go GPS Grafton Grandchild Grandpa Harry's hazing Healthcare Healthy Choices while Dining Out Help Desk Hisa Japanese Cuisine Historic holiday Home Home Inspection hope Horizons hose Hot Dog Hurricane IIT Assessment incident Indecision Indian Infrastructure Inn Innovation Insurance Internet Inventory Management iPhone IT IT Assessment IT Satisfaction Italian Jack Daniels Jakes Restaurant Janet Japanese Jazz Joey's Bar and Grill JP's Khatta Mitha kickball kids Laid off Lakes Region Lala Java Leadership Learning legacy Legal Legal Harborside Les Zygomates L'Espalier Liberty Wharf lights out Linguine's loss Love Lucky's Cafe luxury M&M Macys Thanksgiving Day Parade mai tai Managed Application Services Managed Services managers Mandarin Manners Mark Fidrych marriage Mary Chung mass save Maxwell-Silverman Mediterranean meetings Memorial Day memory Mendon Mergers Mexican MiFi Migration Ming III miss MIT MIT CIO Symposium Mobility Moes Hot Dog Truck MOM money Mother MoveWithGary Moving on Name neanderthal neighborhood Network New York Marathon newborn Northborough Not Your Average Joe's Nuovo Nursing On-Call Operations Operators Oregon Club Organization Pancakes Pandemic Parental Control Parenting Patch Peeves People Perserverance UMASS growth Play Plug and Run Predictable Pride Problem Process Production program Project Management propane PTA. PTO PUE QR Quick Response Rant Real Estate Realtor Recognition Red Rock Resiliency Respect restaurant Restaurant Guy RFP ribs Ritual Root Cause Analysis rReal Estate Sam Adams Sandy Sapporo savings School Sea Dog Brewing Company Sea Dog Steak and Ale Seafood Seaport Security Sel de la Terra Service Service Desk Service Indicator Light sharing ShearTransformation SHIRO Shit Pump Shriners SHTF Simplification Skunk Works Skype Sleep sleepovers Sloan Smith & Wollensky soccer Son SOP sorority spanking Squarespace staffing Starbucks Status Reporting Steak Steve Jobs Storage Strategy stress Summer Sushi swimming Tacos Acalpulco teacher Technology Teen Telephony Temperature Strip Tenka terrorist Testing Texas BBQ Company Text Thai Thanksgiving in IT The Mooring Thomas Thought Leader Three Gorges III TIA 942 Timesheets Toby Keith Toddlers traditions Transition treehouse turnover TV Twitter unspoken moments Valentine's Day Value Vendor Venezuelan Verizon Vermont Video Vietnamese voice VoIP Watertown Wedding Westborough Korean Restaurant Westborough MA. StormCam WiFI Wi-Fi Wilbraham Wine Worcester work work life balance working Yama Zakura Zem Han Zitis
Thursday
Dec102009

Vendor Communications Bill of Rights

Most of my telephonic career has been spent receiving phone calls from vendors, with an additional 25% of vendor communications over email. Now I’m a vendor, and am astonished with the communications norms of companies.

Suppliers don’t understand what it is like to be on the firing line. Suppliers don’t get paged when something breaks in the middle of the night, and it’s expected you’ll be in late after entertaining a client. Add in performance reviews, 1:1s, budgets, etc and the day easily slips away to “wall to wall” meetings. Asking you to meet at 7AM (or 7PM) isn’t meant to be a negotiation technique; it’s a survival tool.

Companies don’t understand suppliers are trying to hone their message to meet their needs. As a generality, reputable vendors are focused on addressing an issue focusing on the remuneration second (of course it’s expected if the solution is good.)

In discussing this with some other supplier friends, they had a similar reaction, and offered the more senior the person the more likely a return conversation. So this post isn’t for the top of the house, it’s for the mid to emerging talent, written from the perspective of the company having suppliers calling on them.

Vendor Communications Bill of Rights

  • Cold Calls, direct mail, and broadcast emails – We reserve the right to delete these in the fastest way we can. Vendors cannot possibly expect calls back as we receive many of these daily.
  • 15 minute follow ons – If you have a solution we may be interested in, we will have a short follow on meeting. This allows us to quickly determine if more time with a broader audience makes sense.

    Suppliers are taught to let us talk.
    In our first session, we want to know what you have to offer. Use this time wisely; using 15 minutes to talk about the history of the supplier company makes little sense.
  • Follow ups – we will get back to you either:
    • When we commit to get back to you. If we say one week, we will reach back in a week. We know our calendar and other commitments
    • Within 24 hours – since we are in meetings for great periods of the day, we’ll get back to you when we can. In many cases, we can only reach back before or after the traditional workday. Please do not take it personally if we are not responding immediately.
  • Saying NO – we will be clear when NO means “no” and when it means “GAME OVER.” We understand the selling starts at “no”, and understand you’ll come back. When it’s “game over”, please respect our decision. We will advise you of our decision within the decorum of sound vendor relations
  • Doo Dads, etc. – We have shirts, pen and pencil sets, coffee mugs, thermometers, desktop tool kits, golf balls, etc. Please don’t cheapen our relationship by giving them to us. And in some companies, we can’t accept gifts and it puts US in a bad position. Leave the merchandise in the car.

    Dinners fall into the same category. Given our overburdened schedule, it’s hard to make time in the evening for a dinner. If we have a lunch meeting, let’s do it in the office and bring some nice sandwich wraps.

    We know this puts you in a bit of a bind because you are supposed to spend time with us developing a relationship. We’d rather focus on the business challenges together in developing relationships.
  • RFIs, RFQs, and RFPs – we are issuing “request for” documents to get additional items of information on an effort. We know suppliers abhor these documents unless they wrote them. Please recognize your response is important and take the time to put together a nice package. We know when suppliers are simply going through the motions.
  • End Runs – Suppliers are adept at working relationships at all levels. We understand this. When we tell you “GAME OVER” and you escalate around us, you do so at your own peril.

Sunday
Nov292009

Provision a Data Center in 30 days

This is not some cleverly named cloud computing article. This was a real requirement.
(I will leave the details around how this company got in the situation of needing a data center in 30 days….clients find themselves in situations from time to time, either due to growth, capacity, or outages.)

The key to performing data center miracles rests with the network. If the network is near the facility, you’re golden.

This company had two main wide area network vendors (household name companies), and two major ancillary metropolitan area network providers. We felt we would have no issue finding a co-location site within the geographic boundaries some of the technologies required.

In this particular case, we needed a modest “cage” in a larger facility. We came up with our short list fairly quickly, and promptly went out and toured facilities. One facility percolated quickly to the top of our list; two of our network providers were there, the facility was in walking distance of another one of the company data centers, and we discovered the facilities manager was a alumni of a past employer.

This started a massive parallel effort.

The staff was fully brought into the decision, the business need, and helped plan the transition. Circuits, servers, storage arrays, etc. were all ordered immediately as the contract with the co-lo facility was worked out. Hardware vendors are used to performing miracles; they often install a large amount of equipment leading up to their quarter end.

While all vendors began responding, one communications vendor balked. They had a process, and as a part of that process had timeframes, and those timeframes were incontrovertible. We met with the vendor, and you could almost see the “A crisis on your part does not create a crisis for me” sign on their foreheads.

We went to the other communications vendors not in the building and made our case. One company, a scrappy start up charged with selling communications along utility rights of way, acknowledged have services “in the street,” but would have to get approvals from the City. (Full disclosure. This was Boston during the Big Dig. Every street was torn up on a tightly coordinated plan. The issue wouldn’t be getting the approvals, it would be getting Big Dig approvals.)

One thing scrappy start ups often have going for them is they are nimble. This supplier had the street open within a week (at night, no less), and brought new facilities into the colo site. It was good for us, and over time they certainly got additional business.)

Following the same process and using vendors used before allowed us to accelerate the delivery. The electricians “knew” what we wanted (once we gave them requirements,) the cable plant was put in by the usual suspects, the security department deployed full badge readers and security cameras, etc.

By following the same processes, our team was able to deploy on a predictable basis. Certainly some long nights were required, and this was a sacrifice made by the staff. Since they understood the business need and Information Technology imperative, they responded with aplomb.

And the facility was up and running on time.

Processes and engagement allowed the IT area to meet the business need. Processes run amok had one communications vendor wondering what happened.

By focusing on repeatable and timely process, this excellent team delivered!

Friday
Nov272009

When Technologists Inhibit Technology – a VoIP Case Study

I am a Voice over Internet Protocal (VoIP) bigot. It works, it is cost effective, and it allows fast deployments of advanced capabilities. I have installed in numerous US cities, as well as Japan, China (Beijing and HK), Singapore, Australia, and the UK.

With a solid network (and this is key) you can hear a pin drop.

Yet some are still buying (new) installs of TDM phones (Time Division Multiplexing A technology transmitting multiple signals simultaneously over a single transmission path.) I can understand expansions of existing systems, but am struggling with why a new implementation wouldn’t be solely VoIP.

Let’s look at what you can do.

VoIP uses your dial-up, broadband connection or corporate network to make telephone calls over the internet or your corporate network.

Some people argue it’s not reduced to practice.

Let’s look at some business cases. This post is being written in late November, 2009. At this writing, there are 18, 224,622 users online with Skype. By comparison, EBay claims 88 Million active users. Active vs total isn’t a good comparison, suffice to say Skype has mass. Full disclosure, EBay just sold Skype for a deal valuing the business $2.75 billion. Around the same time, Avaya announced it was selected to acquire Nortel Enterprise Solutions for US $900 million.

During the third quarter of 2004, VoIP surpassed TDM phones 1.796 million VoIP lines were shipped compared to 1.793 million TDM lines. Somebody is using this stuff, and it must be successfully used or people wouldn’t still be using it.

In a corporate environment, a well designed network allows for calls to be routed to a local point of presence, saving on long distance toll charges.

With VoIP, “soft phones” are easily used. A soft phone is software running on a PC. In my business, we use an outsourced Asterisk PBX, with Polycom phones. My PC has CounterPath’s Bria softphone. Whenever I have a network connection wherever I am in the world, calls can be made and received on the PC. As a road warrior this functionality is invaluable.

VoIP systems generally all allow more advanced features, such as meet-me teleconferencing, and simultaneous ringing of multiple devices.

So what is the hesitation of some technologists to use VoIP?

I was at a car dealer today who had recently installed a newer generation Avaya TDM system. When asked why he didn’t buy a VoIP system, the dealer owner said he went with the recommendation of his technology vendor.

Hence the issue.

Some technologists are holding back on new technologies preferring to ‘go with what they know’ rather than getting into newer technologies. Yes, VoIP requires a solid network, and preferably one with Quality of Service (QoS) enabled (a networking technology prioritizing network traffic so ‘voice’ calls are not interrupted by general purpose network traffic.) Without a solid network environment, VoIP can be troublesome. I’m sure the car dealer rarely has phone issues with an older style TDM system, however they are paying more than needed.

When someone calls the “phone company” with a small business need, the data and voice sides of the house are often different. So compensation plans work against implementing an overall best in class service.

So technologists must think in terms of what they know, what they can support, and what’s best for their client. To be clear, I am not suggesting blanket installation of bleeding edge technologies. To the contrary, we need to provide solid technologies. Back at the car dealer, a simultaneous ring of the desk and cell phone is a win:win for the sales team (who might be out on the lot) and the customer (who probably doesn’t prefer voice mail.)

In the case of VoIP, leading companies are now working on unified communications strategy. Unified communications (UC) is the integration of communication services such as instant messaging, presence information, VoIP, video conferencing, call control and speech recognition with communication services such as unified messaging (integrated voicemail, e-mail, SMS and fax).

Technologists need to consider where technology is going, and make sure the building blocks being implemented are beneficial to their clients.

Thursday
Nov192009

Why IT is Failing

I just returned from the Interop New York show. Let’s declare we are interoperable, and still failing.

The Interop show seemed small and rather dull overall. To highlight interoperability, there was a “Network Operations Center” (NOC) containing 8 racks of vendor equipment used to run the show tucked away in a back area. The NOC also has a NASA-Houston-like area for onsite support from all the vendors (who looked typically bored). It’s an interoperability show, so all the vendors were playing nice-nice with each other.

The only vendor I saw even comparing products in a display was Xirrus comparing their Wireless Access Point (one large Frisbee-looking device) to an Aruba array of devices. Neither product set will win aesthetic awards from picky office designers, but I digress.

The only vendor having a visible “issue” on the floor when I was there was Microsoft; their “Surface” table appeared “down”. Things break, Microsoft’s biggest failure was not anticipating an outage and running a canned “video” on the large display screen in the “Surface” demonstration area. If you ever do a trade show, have contingency plans for the technology!

So why are we failing? The issues in IT today are the same as 20 years ago…we haven’t figured out how to effectively integrate systems.

Today’s media darlings Cloud Computing and/or Software as a Service have their roots in approaches dating back to timesharing in the 70s. There are lots of firms being engaged to integrated disparate systems, whether in the cloud or in the enterprise.

Let’s take a simple example. IT comes out with “Business Intelligence” systems, which are really little more than expensive attempts at report writing. They often fail because the mere mortal still needs to understand the (meta) data. So these expensive systems end up being used by a few “super users” who probably would have done just as well learning how to use a less costly report writer.

XML was a noble attempt to address this by embedding meaning with the data….but our USERS (or clients) are not seeing the benefit.

Take the garylkelley.com blog. We’re using all industry leading freeware with plugins and widgets to make it work…and yet we still need to do some “coding” to make it hang together so your experience (and ours) is useful.

My sense is Apple comes closest to having a seamless experience. They’ve worked hard at it, and it shows. As an IT-type, let’s architect so systems integrate seamlessly and let us provide breakthrough business process improvements. As a user, please stop inflicting painful upgrades on me… my recent Windows 7 upgrade took Dell (paid) support 7 hours to troubleshoot audio issues after a 2 hour upgrade. Argh.

We’ve largely figured out interoperability. When are we going to address the integration conundrum?

Thursday
Nov122009

Information Technology Crisis Management

“I don’t believe in Disaster Recovery.”

What a pretty bold statement in an initial interview. The interviewer/hiring manager was a former executive of a major “hot site” company, who played a pivotal role for many clients during the World Trade Center bombing of 1993. He had a fiery reputation, and visibly stiffened at the comment.

My second sentence put him at ease, reinforced our value set, made us friends for life, and most importantly got me the job!

“Preparing for the ‘big one’ solely can leave you ill prepared for the myriad of daily events nipping at us every day. Prepare for the daily events, and use the same process for initiating processes for the ‘big’ events.”

While firms spend millions on high availability, redundancies, balancing, geographic diversity, N+1, etc., inevitably “perfect storms” lead to user impacting outages. How IT staffs respond in a crisis can differentiate companies and impact the bottom line.

The key is having everyone understand their goals, roles and responsibilities in a crisis. And during a crisis, there may be a change in an individual’s role as needs warrant.

For example, once an issue escalates to a crisis it’s useful to have at minimum two communications outlets. There needs to be management discussions focusing on impacts, alternatives, communication (to users, clients, regulators) while the technicians focus on eliminating impacts and understanding root cause.

Who is involved in each grouping is best determined in the calmness of an outage free period.

Management groupings will often include the CIO, Human Resources, Security, Public Relations, Business Continuity and the impacted business area. Technical groupings will include representatives of all the major functions, with one area tracking all the activity and logging for subsequent analysis. Frequently, the techies establish their own information communications using instant messaging or Twitter (used in a publish-subscribe manner.)

When a crisis is apparent, the notification and escalation processes have to be well honed. We often see organizations operating on predetermined voice “bridges”, with notification via text, email, phone call (in many organizations this is via an automated notification system).

There needs to be a protocol for entering the bridge, doing roll call, and general etiquette around bridge participation.

These processes are best developed in advance of need and rehearsed with staff in table top exercises.

When Information Technology leads the way in developing low overhead crisis response, and orchestrates rehearsals reducing the processes to practice, preparedness for managing the “big one” is well underway.

 

Tuesday
Nov102009

Doing the Right Thing

The new phone and voice mail systems were just being deployed. Everyone was thrilled…there were even posters up “Free Yourself from Telephone Tyranny” with a tie in to the July 4th implementation.
Everything was going smoothly until someone asked why the message waiting lights on the general purpose phones were not coming on.

When asked, the telecom manager replied, “We didn’t buy the circuit packs to light the (message waiting) lights except for the executive phones. On all other phones, you’ll have to listen for a stutter dial tone. We did this to save money.”

Quickly, the inconvenience for a couple thousand people was dollarized, and the message sent to those same people by the blissfully unaware hundred or so Executives (whose voice mail was rarely used as the administrative assistants answered all calls) was hypothesized. While saving capital dollars is always desirable, impacting many people daily over such a minute cost was shortsighted.

Within a week, the message waiting lamps were lit, with negligible project cost impact. When they wrote the history of the company, the message waiting light faux pax wasn’t even a footnote.

In this case, a willing vendor made the correction relatively simple albeit at a modest cost. Not all suppliers are as willing, and the costs could become relatively unreasonable.

Doing the right thing means sometimes sucking it up, acknowledging the issue, and correcting it. Be up front about it; don’t try to hide the error or omission.

It would be simpler to know about the tradeoffs before the orders are placed. How do you do that when some vendors’ orders are actually parts lists in some unintelligible logistics language? While suppliers may argue they have unbundled pricing allowing unique responses, often we find the pricing models are intended to obfuscate the actual costs and this can lead to functionality/pricing surprises later.

Insist on a line by line review with the supplier. It may be painful, and it is up to the vendor to make it intelligible. Like buying a car, sometimes options packages create opportunities (i.e. the wood grain steering wheel you like is included in the luxury package.)

You’ve received references from the vendor. Meet with the references and review your order (without sharing pricing.) Of course, vendors won’t give unhappy referrals. At the same time, these companies may have learned the hard way options to get or avoid.

Require a lab set up where you can use the systems in practice. In the example from this article, “testers” needed to understand the requirements and assure the solutions meet the needs (not simply that the system works…it needs to meet the need. Therefore, testers need to be willing to say something works and doesn’t meet the need.)

Ask your staff and the supplier what tradeoffs were made, and are there any glaring omissions. In every case, these articulations can be used to determine whether something ‘critical’ has gone missing.

Oftentimes technicians will try to “hit a budget number” rather than taking a step back and laying out the wisdom of expenditure. Budgets are put together months before the actual numbers for a project come in. And if suppliers gave you a “budgetary number,” rest assured there’s room to negotiate on scope as well as price! Doing the right thing means providing the right functionality at the lowest possible overall costs…even if that produces a budgetary impact.

It often comes back to having clarity around the assumptions and requirements. External firms can be brought to bear to help review requirements and identify shortcomings. This is often money well spent on major projects and initiatives.

George H. W. Bush put forward an idea in 1988, based on the phrase “a thousand points of light,” encouraging individual contribution to society. Lighting a thousand message waiting lamps may pale by comparison unless you are one of those impacted. Be bold and always do the right thing.

Saturday
Nov072009

Lessons from the Dogs

My business partner and I both love dogs. In fact, we both have beagles right now. My family dog Sam is pretty experienced, and Matt’s beagle is a puppy.

We recently had the opportunity to get the pets together, and remarked the similarities of the two beagles meeting to people in business.

Milo came to visit Sam in his yard. Sam has the run of the yard. Sam has a Dog Watch invisible fence, so the yard appears wide open. Milo was on a nice long lead. Sam was immediately interested in the new being in his yard. Both dogs walked around each other warily, checking each other out.

All of a sudden Sam’s fur popped up, and he let out a mighty bark, as much as to say, “this is my place, watch yourself.”

Milo wasn’t deterred. He marched over to Sam with an incredulous look, “what’s with you?” Sam took a step towards Milo, and let out another substantial bark, “I’m the boss.” Milo immediately rolled over onto his back.

They did this a couple times, with Sam declaring his superiority and Milo being submissive. Eventually Milo decided this was a silly game, and started to explore other parts of the yard. Sam kept giving out singular barks, and Milo simply ignored him.

Eventually Sam decided to stop barking, and began exploring what Milo was exploring. While Sam could have gone anywhere in the yard, he stayed close to the leashed Milo. The dogs continued sniffing around each other quietly, with Milo occasionally nipping on Sam’s tail.

Sam eventually went about his thing, leaving Milo. With that, Milo let out a mighty puppy bark. Sam largely kept politely ignoring Milo, who let out another bark. Sam then came back over, and the two dogs played with each other.

We then went inside, and Sam took Milo under his guidance. It was lunch time, and Sam holds a Masters in begging. Milo was quickly learning.

After lunch, Sam enjoyed a good nap, while Milo explored the house.

In the workplace, it’s not uncommon for the more experienced team member to be a little wary of the new team member. Even when they are the same “breed”, there’s a getting to know each other period.

It took Sam and Milo about 30 minutes to figure things out and get comfortable with each other. In the workplace, onboarding new team members successfully should be a focal point for any IT group.

Friday
Nov062009

Operating Globally

“Global Experience Needed.” What does that mean?


Having had the opportunity to lead projects in Sydney, Tokyo, Hong Kong, Singapore, Beijing, London and Cleveland (I can say that, I was raised there!), working globally isn’t really all that hard. Some basics will help you navigate.


  • People are people – around the world, people want to do a good job. They need to know what you need to help you be successful.

  • Global Companies are not Global – Global companies are made up of various legal entities and while they may share the same logo, local practices often differ from country to country. Be specific. Don’t assume one company acts one way.

  •  Global Companies often outsource – Large multinational companies have a web of local suppliers to deliver services. Find out who is specifically doing the work, and how they are going to be managed. Be clear on whom to hold accountable. This is particular true of communications companies…where the “last mile” is often a “local” provider (often impervious to SLAs established in faraway places.)

    Of particular concern is measuring deliverables. The adage, “Trust and Verify” fits. In some areas of the world, it is unacceptable to discuss project delays. So the status will be positive right up until the missed delivery. As you might expect, people missing status updates is often a red flag for issues.


  • Be specific on specifications – don’t assume anything. Paper sizes are different, power attributes are different, codes are different (“Exit” signs in Beijing must be near the floor. When you think about it, that’s a sensible location especially in a fire!), and “standards” are different. Take the time to make sure everyone is talking the same thing.

  • Look for nuances in language – Make sure there is tacit agreement. While English is often the language of business around the world, be respectful to the party you are speaking with. They may not understand colloquialisms or humor. It’s not (always) a lack of a sense of humor, they may need to translate the English to their language and the translation may not be 100%. So when asking parties to agree on something, it’s often useful to ask the other party in the conversation to “summarize the point.”

    Direct confrontation is avoided in some cultures. Care should be used when the discussion could lead to embarrassment. If you sense this is happening, offer to follow up separately.


    The same rules around email apply here as well. When an email exchange begins around a topic, and a “point-counterpoint” ensues (especially with a lengthy periodic cycle), a quick conversation is indicated.


  • Meeting times must be flexible – Depending on your worldly needs, someone is going to be inconvenienced. Most projects will start out “bouncing” meeting times so everyone is inconvenienced from time to time. The complexities of this shifting rapidly lead everyone to the same conclusion, pick a time and stick to it. This means US based staff team members may need to participate in the evening, and vice versa. Keeping good meeting minutes is very important since some people may be tired and not always at their best.

  • Learn some of the local cultural attributes – This shouldn’t be a massive educational undertaking, more of an internet research exercise. Start with the CIA’s reference https://www.cia.gov/library/publications/the-world-factbook/

    What you are trying to do is learn about the local culture. You don’t want to unknowingly create a faux pax (For example, asking someone from India to attend a steak dinner. The cow is sacred in Hinduism. Need a quick meal in Hong Kong? KFC is the largest restaurant chain there.)


  • You can work 24 hours a day – assuming different timezones, at minimum you can day extend work on a project. Having handoffs between teams on a “follow the sun” model is important. Keeping documents “in order” is imperative (SharePoint, DocuShare, Google Docs and the like are great tools to help.) Knowing who has the baton at any point in time helps prevent overlap or wasted work.

  • There are great Communications tools – Cisco and Polycom offer high end videoconferencing. Not everyone will have this gear at home! There are other low end solutions (Skype, ooVoo and others) will allow team members to conference in. Video is great for meetings under an hour, and over video becomes mind numbing.

    VoIP allows low cost calling virtually wherever there’s a network. Some companies have VoIP phone systems; others can use Skype, Vonage or Google Talk.

Operating globally is a mix of common sense, heightened manners, and sensitivity. Projects are accomplished every day. Success is achieved by those taking the time to understand the differences and making goals, roles and responsibilities clear.

Thursday
Nov052009

The Impact of Simplification





At the CIO’s first department meeting he shared the story of the Pig and Chicken.




“While having bacon and eggs for breakfast you realize there were two parties involved in that transaction, the pig and the chicken. While the chicken was involved (laid the eggs), the pig was committed. I want all of you to be pigs.”

While the CIO was outstanding at motivating an audience, what I remember most about this experience was how one simple story could inspire so many people.. For many years, everyone in the Information Technologies department took great pride in calling themselves “pigs.” Vendors who sold hardware and software to us and did not take a personal interest in the sale were known as “chickens” (they had no idea of what we were talking about). We purchased pig and chicken pictures and statues and gave them as objects of recognition. We were sold.


It seems like the art of simplicity has been lost. Everything we do, today, must be complex and require a sophisticated explanation. We used to say “If it is in a report, it has to be real, and if a spreadsheet is embedded in the report, then it must be accurate.”


The same CIO (someone for whom I have the utmost admiration) stressed the importance of being “pithy and succinct.” I could produce a 10-page memo (correctly formatted and grammatically correct) in less than 30 minutes. It would typically be a “brain dump” and was not well organized. By spending another 30 minutes I was typically able to reduce the size of the document to a page or two and do a better job of making my point. Simplicity, combined with brevity, became my obsession and made me a better communicator.


How can IT professionals simplify communications? Here are some pointers:



  • Craft one paragraph or slide outlining the point you wish to make. This will be your executive summary or thesis.

  • Create a simple outline of the points absolutely necessary to convince the reader or listener of your thesis.

  • Limit your document to 1 or 2 pages and presentations to 4 or 5 slides.

  • Never use acronyms or technical terms.

  • Insure a logical flow from start to finish. When person has read or listened to your presentation will you have proved your point?

  • Have someone, preferably non-technical, proofread your document (this CIO and I would always proofread each other’s materials).


Simplify your message and notice how business users and executives of the firm respond. Communicating in terms they understand cause them to treat the IT organization as equals and increase the respect they have for technology professionals.


Wednesday
Nov042009

Delivering Bad News

To:     All Personnel


From:     Information Technologies


Subject:     System Outage

 As Infrastructure & Operations professionals we all delivered these emails or memos to our users. It pains us when we have to communicate this information, but how and what we communicate ultimately defines the respect we receive from our users and senior management.

 I am reminded of an outage that occurred while I was at a seminar in New York City. Our trading system was impacted while data was being replicated to our Disaster Recovery systems. We could not assess the impact of failing over, so we attempted to fix the problem. I was immediately paged and alerted the CIO. It appeared we would not be able to restore the trading system in time for the start of day so I immediately packed and got the 6:30AM flight out of New York. On my way to the airport I informed the team I would speak to the CEO as soon as I landed. I got on the plane (still on the same conference call from 3:00AM), and who do I see 10 rows in front of me, but the CEO. I couldn’t get to him on the flight so I figured I would catch up to him in the airport. Luckily as I was running through the terminal I was informed all systems were operational and business would proceed as usual. I caught the CEO and, relieved from the news I just heard, joked how it was funny we were on the same flight.

Unfortunately, situations do not always end up this way, and you must find ways to communicate bad news to your users. Over the years, the following guidelines served me well:


  • Determine the sender of the message – The sender of the message will also be the person to receive any questions or comments about the incident and status. A message sent from a person, instead of a generic mailbox, will carry more credibility, but will yield more questions.

  • State the problem in the first paragraph – Let people know what happened in the first sentence. Use the second sentence to communicate business impact. Never use any technical terminology and never describe systems by their internal IT name. Always describe systems by the business functions hosted on the system.

  • Identify functional business systems – The first paragraph notifies users as to systems not available. The second paragraph lets them know systems that are available. Users want to know if they can do their job and your communication must not be ambiguous in this context.

  • Give estimated time for recovery or time of next status message – People want to feel informed and in some control. Frequent status updates helps to achieve this goal. If an estimated time of recovery is unavailable, let people know when the next status notification will be issued. Over time, you’ll be able to either have accurate estimates, or will get a “gut-feel” for the length of outages.

  • Designate a point of contact – Users will have questions. Give them contact information. The Help Desk would be our first choice. Questions will also be directed at Desktop Support personnel as they have the most frequent contact with users. Do not forget to notify them before you notify your users.

  • Do not apologize if it was not an internal problem – Sometimes, third-party hardware and software fail. We try and prevent this from happening, but there are times when it is beyond our control. Only apologize when you have something to apologize for.

As problems become more complex and require larger numbers of IT personnel, we recommend using a dedicated Problem Communication Manager for generating both internal IT and external updates. This will simplify the job of the Incident Manager and provide better service to users.

Defining problem communication processes, people, and templates delivers a higher level of service. Users will appreciate the communication and it will be one less task for IT personnel involved with the problem.