cazh1 » Communication

How to Draw an Owl

Jim MacLennan — Wed, 16 Nov 2011 03:27:41 +0000

On Documentation

One recent afternoon I found myself in deep conversation with potential consulting partners, holding out for a difficult requirement: “Excellent Documentation”. That’s a tough one to quantify, let alone describe; why hold out for something at once critical and ineffable? Doesn’t every project talk about the importance of providing documentation, yet rarely deliver it? Don’t most people flip past the pages of detailed work process, going right to the keyboard to bang away, expecting tool tips and intuitive UI to guide them through? Aren’t most technical teams passive-aggressive on documentation, procrastinating until the final week, throwing something together that the project manager probably doesn’t have time to read and review?

Click on the picture to check it out in book form ...

Still, I will press on candidate firms that want to code/configure for me, to put their manual where there mouth is, and show samples of the documentation that truly allows me to become self-sufficient. Many will piously claim an ultimate goal; to walk away from the project and customer [me], leaving me fully trained and self-supporting – even though [he cynically observes] they are incented to maximize billable hours. (Yes, I know the real truth; consultants enjoy the “fun stuff” – coding from scratch / developing new. Maintenance, extensions, and bug fixing gets boring.)

Of course, the more thoughtful Business Development folks, having been through similar conceptual wringers, will point out the difficulty of quantifying “acceptable”. But it’s not difficult to visualize; like certain non-fiction books, the really well-written ones where structure and prose come together in a perfectly natural way. “It’s like God wrote that”, I like to say, “it couldn’t have been written any other way.” Sort of like the Potter Stewart Pornography Test – “you know it when you see it”.

On Books

This turned the conversation towards books in general – fiction or non-fiction, read for enjoyment only, without regard to platform (paper or plastic). In fact, this is a terrific interview question I like to spring on folks – What as the last good book you read? It’s interesting how often the technical folks respond with Kernighan and Ritchie or the Gang of Four (no no yes), but I really like to talk to folks who want to review the latest pulpy summer fiction, interesting history, or a real brain bender like Hofstadter or Kurzweil. This is a great way to get into how people really think – listen to someone get animated about arcane topics like how to measure things – really big things, conceptually impossible things. You can hear it in their voice, see it in their body language – and it’s this honesty and energy that you want working for you, on the project or the contract …

Back to the Documentation

… and that’s probably the best way to identify an excellent documentation writer – do they get excited and animated about the craft of good writing. Do they know it when they see it – and can they identify why it works for them?

In the end, I agree that this is my white whale, a recurring windmill against which I tilt. Why do people overcomplicate the pictures and the prose, and create confusion out of something straightforward? Is it lack of complete knowledge about the subject matter – or lack of ability to communicate complexity with simplicity?

No easy answers here, and we’re running out of our scheduled time. To help make my decision, I’ll ask for samples; I find the best way to request representative work is to ask for something that the candidate is “proud of”.

Epilogue

An excellent quote near the end of this conversation; “I don’t read manuals … I clunk, I’m a clunker … I Apple” [emphasis mine]. Fascinating how intuitive usability has made a verb out of a brand name and a design philosophy.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: analogies, Apple, communication style, creating understanding, Devil in the White City, Documentation, Hofstadter, Kernighan, Kurzweil, process documentation, Ritchie

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

A Nice Knock-Down Argument

Jim MacLennan — Thu, 21 Apr 2011 02:47:50 +0000

Sales and the Gantt

“Why exactly does he want to meet again?”

I could sense the exasperation in Karl’s voice, faintly; the sales manager wasn’t about to slip out of his professional demeanor over some perceived technical triviality. But for the fact that the request was coming from his newly-hired PMI maven, he probably would have found a convenient excuse to skip the invite.

“I just don’t understand why we need this meeting … the projects are moving forward, we are meeting regulary, the team is communicating status – what am I missing?”

Karl had called me in to his office to help decipher these requests, and I was searching for the analogy that would let me get to my next meeting. “Ah”, I explained, “you are using the terms ‘project’, ‘tasks’, and ‘communicating’ … somewhat colloquially”. The familiar roll of the eyes – I am talking in high concepts, pausing as I speak, trying to compose precise prose on the fly – never a good idea. Karl is checking his vibrating iPhone and wondering if he can make his own next meeting – but we both know there is a nugget of truth here, just have to find the right words.

“Your PM is looking for detailed tasks and dependencies, right? Like a recipe for building a road, constructing a house – a repeatable set of instructions, honed over time, that produce a predictable result. That model doesn’t fit this project; it’s assumes full knowledge of the path to the end … but that doesn’t really apply with a consumer-facing project like this …”. A glimmer of recognition …

When I make a word do a lot of work like that, I always pay it extra

“It’s like asking you for a detailed task plan when you are negotiating the big contract – there is a general path, for sure, but your team always has to find the way to close by navigating the relationships and complexities. Could you write down the steps for a trainee to follow? Of course not – and that’s how your team runs its projects. Not right or wrong – just different.”

And then the lights came on. “Thank You!”, said Karl, “that’s what I needed to hear, simply put, I understand now. I can deal with this meeting now, I’m good .. gotta go ..”

Engineering, Excel, and Expectations

“Why is my machine freezing up? Don’t you know anything about IT?”

I must admit, the 3D-spinning rendition of the button assembly was the kind of flashy technology that people like to stuff a CV/portfolio with – but who am I kidding? I can hack file formats and automate PDF renditions, but debugging drawing layers and block interference in a 2M, 15-page technical drawing?

“Look, we install this stuff, but we can’t run it for you. I put Excel on the desktops of everyone in Finance, but I don’t write their spreadsheets for them.”

Deadline tension has a way of stressing the plasticity of common sense, and Mike’s expectations were a little out of true here. He actually laughed at that one – but the machine was still poking along, so he returned to the Task Manager and his Google searches, a tad less grumpy.

Executives and the Blank Slate

“There has to be an easier way”, said Sandra, the impatient executive.

Unfortunately there wasn’t; like most mature ERP implementations, earlier software didn’t quite cover the requirements list, and a bit of customization gets added here, here, and here. And, as entropy reliably applies to business process and code repositories, that stuff gets complicated after 10 years – hence our suggestion to reimplement the base ERP for this latest strategic acquisition.

“Why can’t you just tweak it?”

I’ve come to despise that word – co-opted from the hardware hacker’s lexicon, it has become a common term used by the non-technical to minimize and rationalize a patch, exception, and/or other workaround to deliver results with the minimum amount of near term effort. And, since IT is woefully unable to glibly quantity TCO, the tweaks persist.

But not in this case; since we had the opportunity [acquisition budget / slush fund] to reimplement [... if I knew then what I know now ...], the suggested approach was to create a new instance, model the business in a clean system, then “convert” the existing data into the new instance. Manageable, simple, some time involved – completely understood. However, our “tough customer” wanted to understand why we would do it that way, as opposed to “fixing” the application in place.

“You can start with a clean sheet of paper, or you can keep erasing over the old one”.

What a reaction – silent stare, then “Wow, that’s perfect – concise, complete – I get it!”. The mood lightened noticeably; Sandra couldn’t believe I had come up with that one one my own.

The Vendor Rep Brings Me Down to Earth

My own Blackberry buzzes, snapping me out of a self-satisfied smile. And my drinking partner for the evening snaps me back to reality, out of the reverie these old war stories had brought on.

“Yes, Jim, that’s how we are taught to close the sale. Make the solution relevant to the decision maker, using examples and analogies from their own experience – makes it easier to get over the objections”.

“Gee thanks”, I griped, “thought I had stumbled upon a secret recipe there.”

But then our conversation turned to the creative application of styles and approaches from one discipline to another; mash-ups in the change management world, as we passed the time until the rush hour subsides.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: abstraction, analogies, BlackBerry, business conversation, business savvy, CEO, creating understanding, elevator speech, euphemisms, Gantt, imagination, Project Management, project manager, short stories

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

The Hegemony of Large Numbers – Ignoring Common Sense

Jim MacLennan — Tue, 01 Mar 2011 02:32:28 +0000

Ok, maybe I’m stretching the meaning there, but that’s a cool sounding title, and what I see as an interesting phenomenon. People get excited about Large Numbers, and think they have meaning and importance simply because they are Large Numbers.

The Law of Large Numbers ...

Big Errors

For example – years ago, when an application manager was whirling around the office in a minor uproar, worrying that that someone accidentally keyed in a $1B line item on an invoice.

That’s $1,000,000,000,000 – for the Unit Price.

Well, come on, that number is so ludicrously high, the error condition sticks out like a sore thumb. A single order like that is 1000 times our annual sales, for goodness sake – no one would let an error like that get all the way through to the month-end closing documents, or the daily sales report, or the AR reports. And no one would believe it if they saw it there.

So just calm down and reverse the error – maybe add a little data entry validation to prevent another such “catastrophic event”. (Note – this was in the days of the S/36 and the AS/400 – the user tabbed out of the data entry field, didn’t use field exit).

We should be more afraid of the small data errors – what if you mistakenly introduced a 10% error by transposing a few numbers – what happens then? Cranky customers, lots of backing out, and a difficult needle in the haystack to find.

Big Benefits

Projects these days need lots of business justification to prioritize above the many others vying for attention. But a benefits statement that claims $100M in costs aren’t getting allocated correctly? Where’s the real benefit here? Not $100M, but making the overall profitability of the products or customers in question more accurate. Not a lot of quantifiable benefit there – but $100,000,0000 looks so impressive.

Or maybe the classic “sales force automation” justifier. If I can make my sales reps just 1% more productive, and annual sales are $100M, then surely we can justify spending $1,000,000 on the Fancy Software System. The big numers make for compelling math – but will you get the sales force to commit to the incremental revenue? A difficult task, typically.

Common Sense Helps

Everyone is busy, everyone working hard and trying to make things happen – and unplanned interruptions or competition for scarce resources (including time!) can lead to interesting reactions to such Large Numbers. Unfortunately, most folks also do not have enough time to pause and reflect on the reality that those numbers are trying to express. Realistic? Rarely.

Just count to 10 … slowly …
(that’s not too large of a number …)

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: benefit, business savvy, errors

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Business Proposals and The Lesson of Jabberwocky

Jim MacLennan — Mon, 29 Mar 2010 00:10:00 +0000

Twas brillig, and the slithy toves ...

When someone asks my opinion on their writing, I’ll get fairly detailed; I’ve noted in the past that there is a lot of power and influence in the written word, and it’s fairly important to get it done well, or your project proposals just never seem to get off the ground.

This particular proposal suffered from a lack of direction; it didn’t take the reader (the decision maker) through a clear progression. Admittedly, the subject matter was a bit technical and mildly complex; even though this was a proposal for internal IT eyes, the prose didn’t flow, and did not help the reader understand what we are asking for, and why.

I suggested that the subject matter – highly technical services – shouldn’t impact the difficulty we were having in getting the basic idea across. A good way to validate the structure and effectiveness of a written proposal might be to show it to your high school or college-age children. The document should make a cogent argument that a reasonably intelligent person should be able to understand; it doesn’t matter if they understand the technical specifics!

I saw Alice in Wonderland a few weekends ago, and noted that the plot takes a lot from Jabberwocky. Now, I’m not a “Carroll scholar” by any means; I recognized it, was even able to recite most of the lines – but I blame my high school English curriculum. It was [way] back in my sophomore year – we spent a week or so deconstructing the poem, and the teacher pointed out that you don’t need to understand exactly what a jabberwocky is, or what a vorpal blade looks or sounds like – you can identify these foreign-sounding words and concepts (a Jabberwocky is a noun, vorpal is an adjective, and snicker-snak is an alliterative, sounds-like description) in context. You understand the story and the drama in the poem without completely understanding the specifics in the dialog, because it is a well constructed story.

The same goes for this technical proposal. This should be an effective writing piece made to educate; a business proposal, arguing for action or caution, must make an effective argument. The document’s structure has much to do with the success or failure of the proposal – technical details are for a secondary, deep-dive pass, but the basic business argument should be apparent.

Historically, we have seen X
Recently, Y has changed, to Z effect (X is worse than before)
If we take action Q, we can get back to X.
Q will cost J dollars, and bring K benefit within L months

Currently, we are at The As-Is.
Future state will be The To-Be.
We can get there from here if we execute The Action Plan,
at a cost of A dollars and B people’s time over C months.

External Event Alpha requires us to be at future state Beta
We have two alternatives:
- Plan 9, which will cost 10x and require 1 dedicated Framistat – and be delivered in a year
- Plan 10, which will cost 100x and require 5 dedicated Framistats – and be delivered in a month
Due to Factor Gamma, we recommend Plan 10

As a good common sense check for your writing effectiveness – run it past someone outside your team, someone with solid business sense but not necessarily a deep grasp of the details. There are many patterns for laying out persuasive arguments; learn them, before someone takes a vorpal blade to your next project plan.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: abstraction, Alice in Wonderland, benefit, buzzwords, charter document, communicating complexity, communication style, project, proposal writing, vorpal blade, writing

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Technical Debt and the Cost/Benefit of Knowledge Retention

Jim MacLennan — Tue, 28 Jul 2009 02:26:00 +0000

A rather rigorous, Financial-sounding title for a high-concept line of thought …

Thanks to Jeff Atwood at Coding Horror, for calling my attention to this article by Martin Fowler on Technical Debt:

developed by Ward Cunningham

Now, before you write off Cunningham as a techie snob or an academic hold-out for unattainable perfection, listen to this healthy dose of reality …

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity, developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

I think most of us have seen this phenomenon before; sometimes it manifests as an open willingness to trade quality as just another feature (as measured by the amount of testing before code is put into production). Documentation is another common sacrifice – too often we accept e-mail summaries or PowerPoint outlines as a reasonable facsimile for knowledge capture.

You’ve probably seen this phenomenon where you work, and not just in your IT organization. Many areas of the business will rationalize over-budgeted schedules by summarizing critical findings in a brief email – or, worse, in a Status Update Meeting. “This is an expensive meeting”, I might quip upon entering the room, seeing the conference table ringed with upper-and middle-managers, each weighing in with their understandings and opinions. Don’t misunderstand me – these are typically very effective conversations, with exactly the right people; the folks that know and live the issues, and fully understand the implications of any process change. But my witty entrée was tragically accurate; the understanding and decisions developed at this meeting are too often lost a few minutes after the meeting ends, ideas with a half-life approximately 10 minutes into the start of the next meeting.

Think of it as a knowledge expense (vs. depreciation, as value is lost rather quickly). The expedience and effectiveness of face-to-face communication, with everyone in the same room hearing the same thing consistently and able to ask questions to validate their understanding, typically does not scale beyond the attendees. It’s like listening to a band vs. buying the album (ah, more poetic than downloading …).

In his article, Atwood continues along the Fowler / Cunningham thought process, discussing the need to budget a certain amount of time to pay down our technical debt by going back and finishing that unfinished work; document the things that you sloughed over, rework the inelegant parts of your database schema re code interfaces that rely us a little bit too much on assumptions.

The same can be said for process design and problem solving sessions – remain aware of your level of knowledge debt and budget time to document your findings. I like to call these chunks of captured knowledge “white papers” – I’ll pause while you admire that stunning originality, but there’s a method to my blandness. Calling these things “white papers” helps folks understand the purpose and value of such a document; reasonably short and idea complete. The sweet spot seems to be two to four pages, well-organized, not too wordy, but clear enough that it remains effective months after the design or process rework sessions took place.

Just remember, organizations do the expedient thing all the time, streamlining meetings and decision-making by going light on the documentation. Every once in while, you’ll pay the cost of rework and rediscovery; as our experience grows, and our patience for such “wasted effort” grows thin, task effort times will increase as we invest a little bit more time in better, clearer documentation.

Previously …

Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
The Iron Triangle – Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
Innovation That Matters – Substance Over Style (January 12, 2008)
Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
A Plea for Empathetic Communication (November 16, 2008)
Over / Under Communication for Project Managers (June 29, 2009)

Technorati Tags: collaboration, documentation, Knowledge Management,

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Over / Under Communication for Project Managers

Jim MacLennan — Tue, 30 Jun 2009 01:16:00 +0000

It is often said that you can’t over-communicate, but I’m willing to bet most folks – and especially your project sponsors – underestimate the cost and effort of this critical component of project management. Consider this fair warning – and a good checklist for folks wanting to get into IT, project, or functional management.

Media

To achieve any decent amount of success, you have to be a good communicator with both face-to-face and written / published media.

And by “good” I mean both “comfortable” and “effective”. You should feel good in your own skin, confident that you can carry a conversation at all levels of an organization. And you also have to be an effective communicator – able to get your point across with the right amount of detail, not too much or too little. Another effectiveness challenge is the ability to balance between personalized, one-on-one written & oral communication, and insightful, understandable mass communication.

Translations

You may not realize how many different “languages” you speak – and effective managers must be reasonably fluent …

Languages – Finance, Operations, Sales & Marketing; business groups have just as many confusing specialty words as the techies in IT
Dialects – Do you speak Oracle or SAPanese? Experienced in small companies or large corporations? Public vs. private? Entrepreneurial or slow growth? High volume low profit FERTs, or low volume, high margin custom products? The concepts are all the same, but sometimes the specific words are different.
Slang – Slightly different than dialects – all companies, organizations have local shorthand term so that over the years in their particular organization to mean very specific, nuanced things.
Sound Bites – A form of speech where a complicated topic is reduced to a single word or phrase. For example; ATP. Are we talking about master data, settings on time fences, the process of checking for availability, or the policies around A, B, C and D companies? Sound bites can sneak into conversations and you could be discoursing for 15 minutes before you realize you’re talking about two vastly different things.
Strata – Management v. line, Middle v. executive management. Depending on what level of the organization you’re talking to, you will need to change the level of detail that you go into. Typically, higher up in the company means a lower level of detail that they want to wade through.

Change Management

Volumes have been written on this topic, but most people have trouble coming up with a concise definition of what this means. To oversimplify – but drive right to point: change management is typically about delivering “bad news”.

However, “bad” can mean different things. It can be “disappointment”: the date will slip, we’re over budget, or we can’t fit this feature request into the schedule. However, adjusting expectations as early as possible is one of the basic skills of a good project manager. You need to be willing to deliver bad news like this as early as possible.

The other significant area of “bad” – walking into an organization, a group of people, or a individual’s cube, and letting them know that the way they have been doing things for years is about to change. Sure, it’s easy to say that “change is hard” and “change is inevitable”, but you yourself probably don’t like change in your established rituals. Empathy is the key here.

Lessons Learned

As with many other things, the more project communication you do, the better you get. Some of the more common lessons learned:

Defensive project teams will often negotiate for delay by asking for / waiting for More Communication, and complaining about Not Enough Communication
In any project plan, you will underestimate the time required for communication, the number of times you’ll have to repeat the message, and the ability of the team to consume your communication in various forms of delivery media
You will definitely underestimate the time required for follow-up and follow-through to make sure it’s Done
You will overestimate the amount and quality of existing documentation, and the ability of the project team to bridge the gap to the required level of documentation

Here’s the killer -

If you try explaining to management about the problems / challenges of communication, they won’t listen and/or won’t understand (yes, that is a tight loop)

Machines will never replace us – but this is one case where sometimes, you might wish they could.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | 2 comments |
Post tags: Change Management, Communication, Dennis McDonald, Project Management, SAP, SAPanese, slang, sound bite, terminology

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

News for Wombats: Taming Unreasonable Requirements

Jim MacLennan — Tue, 27 Jan 2009 01:44:00 +0000

I’ve heard from a couple of friends about some “classic” project requests – dilemmas they have recently faced. These unreasonable requests can be turned into something achievable and, potentially, more relevant / meaningful to the requestor, by approaching the problem from a different direction.

Request for Data: the Analytics Project

Classic scenario #1 arrives courtesy of the external Experts, analytic genii (sic) promising to reveal secrets of profitability and sources of revenue buried deep within our data sets. Their “simple request” is to pull all data from the system – customers and orders, vendors and payments, items and inventories – all classified by OBC; the Obvious and Brilliant Categories that, when summarized and sorted, will unlock our Big Opportunities.

Pulling data from the system is easy, but the desired attributes often do not exist in the system – or, they exist, but we have not (to date) filled in those details on our orders / payments / inventories. So, IT is asked to coordinate the bursting of data into separate spreadsheets, and distributing data sets to various areas of the business, to the people who know how to categorize the uncategorized.

Note the hidden work the consultants have pushed down. IT must frame the question to the business (can you categorize this data?), but they are often left with the task of explaining the original project and justifying this interruption. Remember, when the programmers came in this morning, this Data Collection project was not on their radar screen. Of course, this is perceived as IT resisting, being uncooperative …

Sound familiar? It should, I’ve seen it at many companies, many functional areas of the business. There are some Obvious Truths that jump out when you think about this for a bit …

The Data is not Missing – we just never collected it before. Truth is, if we were already categorizing data this way, we’d probably be paying attention to the Big Opportunities already!
You’re Just Moving the Work from the analysts to IT. True, internal IT will probably know the quickest way to get the most accurate data, but why push off the communication / explanation stuff?
There is a Hint of Diminishing Returns here. If 100% of the data is categorized, a simple pivot table will elegantly show all the data, totaled by attribute and sorting the Big Targets to the top. However, most of the time spent is getting the “long tail” of special cases categorized; wasted work, because they won’t make the Pareto cut.

Aha – that last one gives us a hint on how to slash the amount of work required to get actionable data in a reasonable amount of time. Haven’t the external Experts seen data sets like this a million times? They are, after all, selling their experience in the problem space – why not engage in some targeted research? Based on experience, for companies of our type and size, what do you expect the answer to be?

What cross selling opportunities are the most common?
What aggregate buying typically get the most bang for the buck?
Which product families are typically the slow movers?

Jump start the data categorization by guessing the Pareto sort, and target that data for characterization …

Download 100% of the data – must always be able to do a hash total to prove we have it all
The download / work files have blank columns for every requested attribute
Scan through and mark all the data for the target category

Battling What “They” Say

A similar problem is often faced when proposing system and process change. A classic refuge of the change resistant is to stand behind an Unassailable Truism with a potential for problems …

Not all of Our Vendors are ready for EDI …
A great idea – but how will this impact The Customer?
You can’t apply these changes to All Products …

Well, yes, but this isn’t helping us get to the benefits represented by this Cool New Thing; you are just defining Problems, not Solutions.

Still, this one can be fairly easy to defeat, by getting a bit more specific. Which vendors / customers / products are we talking about? Usually, there are just a few key instances where critical relationships (vendor or customer) must be maintained, or important product attributes will guide decisions / changes. Target these specifics, and don’t try to develop solutions / rule sets that will work in all imaginable cases (diminishing returns, again).

News for Wombats

The phrase comes from an old Monty Python show, where a series of terribly redundant news programs, specific to parrots, gibbons, and wombats, pointed out that in all cases, “no parrots / gibbons / wombats were involved”. (Hey – it’s funny in context. Not everybody appreciates Fibber McGee, either). The point is – when time is of the essence, and you are looking to balance a complete design with relevant action, it helps to focus on the specifics.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: analytics, communicating complexity, data, data management, data warehousing, feature, materials management, procurement, Requirements, sales

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

A Plea for Empathetic Communication

Jim MacLennan — Mon, 17 Nov 2008 04:10:00 +0000

It’s impossible to over-communicate

Sounds a bit strong, but if you think through your real-world experiences, this shouldn’t surprise anyone. No matter how hard you try, your message will be missed by someone …

Problem: It’s all their fault!

Rely on Web 2.0, and …

… they won’t subscribe to the RSS feed; they don’t understand the concept, and have no other information sources that supply feeds
… they won’t sign up for the email notifications; that feature is hidden, no one told them about it
… they won’t read / browse / search the wiki; there are too many unfinished pages in there, and they don’t consider it reliable
… they can’t find it using intranet search – they don’t know where this feature is located. And even if they did, the results aren’t as targeted and “right-on” as Google

So, you try to rely on “first generation” electronic media, but …

… they didn’t read the email, it got lost in their inbox with 100 other new messages today
… they didn’t see, therefore, didn’t read the attachment
… they did not check their voice mail

Even the “old fashioned way” doesn’t always work …

You are having a face to face conversation, but it’s not sinking in because they are checking their Blackberry and thinking about the currently unfolding interruption …

Solution: Don’t jump on the latest communication bandwagon and expect a Silver Bullet – you need to balance flexibility and focus. Different media work for different people, so work to communicate your message using a variety of methods. Of course, if you try to supply all media for all tastes, there won’t be enough time to get any real work done. Just know that there is no one best way to get information out to all who need to hear your message – and adjust accordingly.

Problem: It’s all your fault!

If you can get them to the electronic content, you still have to create content that actually communicates the correct information. Even if they are capable of subscribing to RSS feeds, or opening a document attachment – if the content does not convey with clarity, they won’t catch your drift. Worse yet – if the first one or two samples don’t convey anything, they will stop listening to everything.

Solution #1: Practice practice practice – The only way to get better at anything is to keep iterating.

Observation: It’s no one’s fault – it just is …

Think about it – don’t you receive messages in your inbox that are not clear / difficult to read, or hear about things after the fact or through the grapevine? And don’t you glance at your Blackberry during meetings? When you set your phone to vibrate, you avoid distracting others (good!) but you are invariably distracting yourself (who just called ….?)
Fact is, we are all swimming in a sea of information, bombarded with messages from all sides – and we’re bombarding others as well. A little humility and a lot of empathy go a long way …

Get feedback – if your medium or your content are not effective, find out why. Ask your intended audience what works best for them. Majority rules, so if you have a few email holdouts that don’t know how to set up an RSS reader, do it for them. Better yet, do it with them – and show them what else they can subscribe to!
Understand what the current corporate / organizational / local culture is, and play to that. You don’t have to accept the status quo – but don’t tilt at windmills just because wiki is a cool sounding word that would look good on your resume. Introduce change judiciously, and don’t let it override the goal at hand – you need to get the status of this project updated!
Never underestimate the power of face time. When you craft a beautiful, concise, complete summary of the upcoming meeting, and someone still insists on calling you up and talking about it – don’t look on this with disdain – it’s an opportunity! What was it about the email / document that was incomplete? Was I not clear? Also, since most recipients of project updates are getting them for a reason (stakeholders!!), it’s a great opportunity to make sure they get the big picture, understand the original objectives, and are still in support of the initiative.
Projects end, but relationships go on. It’s always good practice to improve your communications and connections with the various technology and business process teams, in and out of the company. These is always a “next time”, and next time could be that much easier if you are consistently building your foundation of clarity, openness, completeness.

Effective communication is very difficult, and requires constant work. Realize this, model your actions accordingly, and your impact and influence will grow.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | One comment |
Post tags: Art, BlackBerry, Communication, communication style, creating understanding, empathy, feedback, flexibility, Inspiration, Knowledge Management, knowledge transfer, passion, RSS, silver bullet, technical communication, Web 2.0, Wiki, writer

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Don’t Accept Snap Answers Too Quickly

Jim MacLennan — Mon, 07 Jul 2008 02:53:00 +0000

A few years ago, I was working on an interface project, and wanted to have the ERP system send copies of any and all transactions that have changed over the past few days. I’ve done this before on other platforms, so I asked the lead developer what I thought was a no-brainer request:

Do the transaction files capture a date/time stamp somewhere in the record, each time the record is modified – DateLastUpdated, something like that?

His answer came back almost immediately … No. Well, I guess this is possible, but we’re working with a fairly up-to-date ERP, and I’ve worked with enough systems and data bases to know that many/most applications timestamp their records when updating, or maybe write changes to a log file of some sort. And the answer came back just a tad too quickly … so I asked the question again, but this time I took some time to preface my question with an apology (of sorts) …

I mean no disrespect, I am fully aware of your experience and skill on this particular platform – but I need to be clear, because I think I’m asking for something that’s fairly basic.I just need you to be a tad more specific when you say ‘the system doesn’t do that’.

Is it more accurate to say ‘I have never seen the system do that’ or do you know for a fact that that the system cannot do that?

It’s a subtle difference, but it’s important to drill into this level of detail. Most of us are pushed for time and quick to come up with the fast answers, so we can move on to the next item in the todo list. Answering off the top of our head is a pretty normal response, I do it a lot myself, but this was a pretty important feature request because the lack of it meant a ton of additional work in other areas. Besides, I’m humble enough to know there are many features and functions in any platform I’ve ever worked on that I don’t fully understand – never had the need. Plus, I don’t see a ton of wildly original thought and unique features in many of these system that we work with. In cases like this, I’m asking for something that I’ve seen in another platform, assuming that the author of this platform was a reason intelligent person and has added that same basic functionality.

Truth be told – in this instance, the transaction file in question did not have a DateLastUpdated field, and we had to look at transaction logs to get the information we needed. Still, the developer in question had little problem with my pushback; he readily acknowledged that he did not have the layout of this particular table memorized, and had never heard of such functionality – but the concept made sense, and he was happy to look. Besides, if his snap answer was wrong, it would have saved him a ton of work …

Drilling into the specifics like this (do you know No, or do you Not Know?) applies to more than just software developers. Engineers lawyers, accountants, sales reps – many folks from across the business are faced with questions that they try to answer from their Experience, hoping for the Quick Answer. It takes some confidence to question the “local expert” – but if the right questions saves a ton of effort, searching for a workaround – well, that’s an excellent question to ask.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags: Art, date time, Requirements, technical communication, terminology

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Can you, should you, bother Executives with The Details?

Jim MacLennan — Sat, 31 May 2008 01:43:00 +0000

In a recent post on Thinking Faster, Phillips expresses concern about the apparent propensity for project sponsors to skim over the details and jump to quick answers. He’s talking about [what I believe is] a peer relationship, when external expertise is brought in to develop the solution that they (the sponsors) are responsible for “owning” (vision, design, execution, and ongoing support). I’ve seen the same sort of thing in multiple organizations, especially when talking with executives about projects and initiatives that they are championing. It’s a slightly different scenario than described in Jeffery’s post – reporting status “up the chain” versus “to the customer” – but multiple nuances of “don’t bother me with the details” come into play just the same. My only suggestion to Jeffery would be to exercise a little empathy and adjust the message. Management needs to understand the details in spite of their objections or shortcuts; the trick is to understand what’s behind this drive for the quick answer, and adjust the communication accordingly.

Fractal Attention Span

Challenge: People typically work on 7-10 major items at any one time; that’s about as many as the brain can comfortably prioritize for chunks of their attention. Unfortunately, these to-do items / projects are fractal in nature, easily decomposed into multiple tasks and subtasks. Our prototype CEO needs to deliver increased revenue (3 key accounts in play), reduced costs (2 cost cutting and 3 productivity-enhancing initiatives), while driving down inventory (S&OP, SKU reduction, and supply network optimization projects). Oh yes, there is also a pending lawsuit, product R&D reviews, and the board presentation to develop. The VP of Sales has five territory managers working on different aspects of the three key accounts, and two project managers working on the cost-cutting – in addition to ongoing promotional planning and customer service issues. Sally, the lead project manager on the first cost-cutting project, is working towards a launch date of 15 July, and has 10 open issues with varying degrees of severity.

If I’m the CEO, and I have two hours to complete an Operations Review for the entire company, I have maybe five minutes to listen to Sally tell me about her piece of the VPs piece of one of my 10 hot items; do I really have time to hear about usability issues or the challenges of scheduling acceptance testing? All I really need to hear is the specific objective of the project, current status, maybe the next milestone date, and our current expectations for meeting the stated objective (vs. budget and/or need-by date). Anything else and my eyes will glaze over, because I’ve got 20 other people to get through, backlogs in voicemail and e-mail, two more meetings before the end of the day – and I’d like to get home before midnight.

Mitigation: This environment is hostile to knowledge retention (ie. you risk the CEO spacing out), so you need to focus on the critical information. I (the CEO) need to hear a clear objective, a plan to get there, and an active monitoring process. I don’t care about the options available or the decision process for task 4.2.6.a on your plan – I just need to know you are planning the work and working the plan.

“I don’t believe you” might mean “I don’t understand you”

Challenge: Phillips’ post captures his frustration when project sponsors ignore input on usability and data access. Features and functionality are stressed over the intended audience’s capability and willingness to use what is being built. Experience in creating and implementing software-enabled processes teaches you the impact of a poorly laid out web page, but this is experience that your project sponsor doesn’t have. They assume all software is built consistently (look at Microsoft Word and Excel!), and that Google, Amazon.com, and YouTube are “user-friendly” solely because they’re on the web (web = friendly and easy, right?).

Regardless, your [sample] project sponsor is very aware of one fact; their integrated demand forecasting system, driven from a single database for security, consistency, and speed, does not exist. I want to see project milestones that deliver what doesn’t exist!

Mitigation: First and foremost they are correct. This new system we’re building doesn’t exist – that’s why we’re building it. So if you’re talking to me about work that doesn’t directly deliver the list of requirements, I don’t understand why we are wasting our breath.

Here’s the trick; to save your personal sanity and preserve your credibility, assume good intent. They aren’t saying I don’t believe you – they are saying I don’t understand how this topic relates to my requirements. Of course, you must connect the dots between the need for usability [in this case] and the eventual delivery of the expected benefits. The system is only as good as the quality of the data going in.

This is important – when talking about issues, decisions, or work that needs to be completed, you most always tie back to stated benefits.

Nature Abhors a Vacuum

Challenge: Blithely ignoring the fact that the executive team has many other things on their plate (see above) our intrepid project manager lays out five major issues and three options for each one. I, as CEO, got to where I am by Being Decisive and Making the Call – so if you’re giving me the options, I’m going to start telling you what to do because 1) you’re asking and 2) I need to move on to the next agenda item.

Mitigation: Heed that classic management one-liner – don’t come to me with problems, bring me solutions. We all get paid plenty of money to solve problems, and it really drives execs nuts when all we do is define tough problems – and look to them for guidance. Believe me, most organizations will massively empower you to show some leadership and make your own decisions!

Not to worry – there are many control mechanisms in place to guard against bad decisions, but you need to control the message and flow. When presenting to the execs, don’t lay out options followed by your preferred choice – it sounds too much like you’re asking for their choice, that the project is dead in the water without their decision. A better method is to present your choice as the only way to proceed (this makes sense based on X and Y and Z). At this point, you can do a few quick bullets on the options, subtly giving the executive team an opportunity to ask probing questions and suggest alternatives. Trust me – if they have any issues, they will drill into these options and dissect your rationale. But when they don’t … progress!

The Myth of Executive Omnipotence

Challenge: In many companies, the executive team holds a magical sway. The staff adheres to their every whim; reworking this project “because the CFO said we should”, reprioritizing that project down the list “because the CEO wants it that way”. I love asking the “stupid” questions … like Why does this need rework? What exactly does the CEO want to see as a deliverable from this team?. If you find yourself pondering (hmmm, I’m not sure exactly what he asked for, but he was pretty adamant – so we better deliver)

Mitigation: If your neighbor stops by to borrow a ladder or chat up the Fire game this weekend, you might have no idea that they are a COO or Vice President; she’s just a regular person like you and me. So why would you grant them magical status in a workplace environment? Look, if you don’t understand what they want, just ask for some clarification. You can make the [very safe] assumption that they are good men of business, and will react predictably to a business-based conversation. We had two options; here are the costs, benefits, and risks, and here’s why were going to pick option one. If your assumptions differ from theirs, why can’t you have an open conversation to challenge those assumptions?

Sometimes I think people are too self-conscious; no one wants to appear stupid and ask the General Manager to elaborate on what they’re saying, because they aren’t being very specific or they’re making a logical or factual mistake. This is entirely possible, even probable – they may not understand the implications of what they’re asking for, but since you the project manager, are defining problems not solutions, and since I’ve got 16 other things to do between now and quittin’ time, I’ll just start making decisions. I’ve seen plenty of projects get blown out of proportion and swerve down strange side routes because the executive said something, the team took it to be the One True Way To Go.

Update them on what they are expecting to hear about
Keep it to the relevant level of detail
present solutions to any problems that pop up
Anticipate some questions …… but don’t offer up the details until asked
If you failed to write down what they asked for, follow up ASAP… and figure out how to listen better next time!

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | 2 comments |
Post tags: Art, board presentation, buzzwords, CEO, CFO, communicating complexity, communication style, COO, creating understanding, dashboard, emotional intelligence, executive management, fractal, Project Management, Science

All articles, blog entries, and other content on this site are licensed under a Creative Commons License