Eight to Late

I do most of my writing when I’m not writing.

Having said something so clearly contradictory, I think I owe you an explanation. The mechanical act of writing - what I’m doing as I tap out these lines - is obviously done whilst I’m at my computer. However, by the time I begin the keyboard finger-shuffle, I’ve already figured out what I’m going to write. Not just the topic, but much more.  I know what I’m going to write about, the introduction and (broadly) how I’m going to develop the piece.  The hard part - generating ideas and developing them -  has already been done. What’s left is the easy bit; the actual writing down of things I’ve already thought through.

Where do ideas come from? Answering this would take me into the realm of speculation, well beyond my knowledge and experience. So I admit complete ignorance and leave it there. In any case, I’m more interested in finding ways to get new ideas, rather than figuring out where they come from.

So here’s a more relevant question:  are there certain activities that assist in generating  new ideas? For me the answer is a resounding affirmative:  it is while I’m on my early morning walks that I get them.  A writer told me that walking was valuable  not so much for the exercise, but for the ideas. I didn’t believe her until I found the same worked for me. The ideas appear to come from nowhere (I refrain from using terms like subconscious, that I’m not sure I understand).  I could be thinking about something and then, out of the blue, I get this notion which is completely unrelated to the prior thought. It could be just a phrase or a sentence, the mere inkling of a piece, but I can usually tell whether it’s worth pursuing or not.

Once the nascent idea has my attention, I start thinking about how I might develop it.   I find it best to do this right after I get the idea, else there’s a good chance  that I’ll lose the context in which I conjured it up. Consequently, I end up doing a lot of my idea development while still on my pre-dawn perambulation. The development phase also acts as a filter - if the idea is hard to develop, it probably isn’t very good. As a rule of thumb, if I haven’t found a promising development in five to ten minutes, the idea is probably not worth pursuing. However, just to be sure,  I jot it down in a phrase or two (on my mobile, which always accompanies me) and come back to it a few hours or days or even weeks later. Often the second look confirms that the idea is good only for the garbage bin. Very occasionally, I go on to develop these further. My mobile memo pad is full of ideas that never took off.

I’ve stopped trying to analyse where the ideas come from - I’m just grateful that they do.  My AM ambles are a double benefit: exercise and ideas. So, if you’re suffering from bloggers block you could try some strategies for overcoming writer’s block. On the other hand, you could try a  morning walk instead. Solvitur ambulando - it is solved by walking.  

Communication is so important to project success that it has been referred to as the life blood of a project by more than one practitioner.  A recent post by Jack Vinson talks about the importance of  communication across project interfaces - interfaces being  boundaries between different groups within an extended project team.  He views  interfaces as constraints that limit project success. On reflection, I realised that many project communication issues  I’ve encountered have, in fact, occurred at interfaces.  In this post I explore the notion of an interface as an obstacle to project communication.

To keep things concrete, I’ll frame the discussion and examples in the context of projects in a corporate IT environment. For these projects the most common  interfaces are:

• between organisations (customer-supplier, for example),
• between departments within an organisation (marketing-IT, for example),
• between teams within a department (testers-developers, for example) and
• within distributed teams (part of the team is in Boston and the other in Sydney, as an extreme example).

In my experience, the main communication obstacles  (across interfaces listed above) can be boiled down three broad ones. I list these below with some pointers to how they might be addressed:

• Political: Whenever there are many groups involved, there’s the possibility of vested interests and power games getting in the way of dialogue. Such political obstacles usually originate in the upper ranks of an organisational hierarchy, a step or two above levels at which projects are planned and executed. Project managers therefore need to make special efforts to be aware of the key political players in the organisation. In traditional corporate environments these might be functional or senior-level managers who aren’t always obvious project stakeholders.
  Once the political players have been identified, the project manager should take steps to gain their confidence and buy-in on project goals.  This should help eliminate political barriers to project communications. In my experience, it is best to settle political issues at the level where they originate - escalating political problems up the hierarchy (i.e. to the manager’s manager)  generally doesn’t help, and may even be counterproductive. Always keep in mind that political issues need to be broached with tact and finesse;   inept handling can be a CLM. You have been warned!
• Cultural:  I’ll first deal with organizational culture , which is essentially the totality of assumptions and values commonly held within an organization. Clearly, this can vary considerably between organizations - some may be more open than others, for example.  Communication at the interface between two organisations with vastly differing cultures can be difficult. For example, one might expect some differences of opinion at a joint project planning session involving a very forward-looking, can-do supplier and a conservative, risk-averse customer. Another example:  in one organisation it might be considered perfectly natural for a developer to air a dissenting opinion at a meeting whereas in another it might not. Project managers can ease such difficulties by understanding the divergences in attitudes between the parties involved, and then acting as intermediaries to facilitate communication.
  In geographically distributed (or virtual) teams, differences between regional cultures can come into play. These could manifest themselves in a variety of ways such as differences in fluency of language, or social attitudes and behaviours.  Here again, the project leader, and the rest of the team for that matter,  need to be aware of the differences and allow for them in project communications.
• Linguistic: Here I use the term linguistic in the sense of specialised terminology used by different disciplines such as Accounting, IT, Marketing etc. Often when specialists from diverse areas get together to discuss project related matters, there’s a tendency for each side to make assumptions (often tacitly) regarding a common understanding of specialised jargon. This often leads to incomplete (at best) or incorrect (at worst) communication.  An article I wrote some time ago provides suggestions on improving cross-disciplinary communication in projects. If done right, project communication can help align IT goals with those of the business. 

A wise old project manager once told me  that over ninety percent of project issues he’d encountered could be traced back to communication problems.  I’m not sure I can vouch for that number from personal experience (I haven’t counted, to be honest), but I’d have to agree that he’s right in spirit, if not in number.  

A shared world-view -  which includes a common understanding of tools, terminology, culture, politics etc. -  is what enables effective communication within a group.  Project managers  can facilitate a common understanding  in their projects by analysing and addressing communication constraints at  interfaces. 

The stereotypical corporate IT employee has a reputation for uncooperative behaviour. The most common manifestation of this is his tendency to turn down requests from the business with a resounding ”NO!”¹.  Unfortunately, this trait doesn’t endear him to the folks upstairs², and a few such refusals soon translate into a company-wide negative perception of the entire IT crew. 

Now, as some say, perception is reality³. So, the employee, despite his ever-mounting frustration with (what he perceives to be)  ever-increasing workloads,  needs to handle his customers with a little tact. He needs to learn how to say “no…” in a softer, exclamation-free, corporately-acceptable manner.

How so? Well, by using positive negatives - i.e. by putting a positive spin on the refusal. There are two ways to do this. By presenting:

• Alternatives: This essentially amounts to saying, “No, but how about <insert alternative here> instead,” or
• Compromises: This is a qualified “yes”. For example, “Yes, but not before next week.”

In either case, our unnamed protagonist would want to ensure that he can actually deliver on the alternative or compromise.

Obviously, the technique of positive negatives works in any area (consultants use it all the time), and the naysaying, nameless IT hack is merely a straw man to  illustrate my point. So - and particularly if you’re a present or erstwhile colleague of mine - be assured that he’s a figment of my imagination.

Footnotes:

¹ Some members of this mob are known to issue relatively verbose refusals such as, “No, that’s impossible because  <insert random reason here >”.

² We are talking stereotypes so the person’s a male, he’s overworked, and the IT department is in the basement - safely quarantined from the rest of the business.

³ See this post and the accompanying discussion for an interesting, if somewhat philosophical, counter-view on perception and reality.

Some weeks ago I sat through yet another presentation that had me drifting into dreamland within minutes.  To stay awake,  I started to put together a list of stereotypical soporific speakers,  much in the spirit  of a couple of my earlier posts on project mismanagers and meeting time wasters.  It was, I confess, the best time I’ve had at a bad presentation in a long time. Without further ado, here’s my list:

Pete Powerpoint: Peter’s presentations are a vehicle to showcase his undeniable virtuosity at Powerpoint.  The content? Who cares. The slides are absolutely brilliant.

Freda Funny-font: Freda loves visual aids. Her problem is that she uses unreadable fonts.

Marty Mumbler: Martin has something useful to say, I’m sure. The only problem is I can’t figure out what it is. His presentations invariably consist of an inaudible issuance of intonations that even those in the front row cannot interpret.

Greta Garbled: Greta has mastered the art of the unfocused presentation.  She manages to cram a lot of diverse  - but not necessarily relevant - material into her talks. It’s quite a challenge to figure out what she’s going on about.

Barry Backside: Barry’s presentations can actually be quite good - if only I could get to see them. His problem is that he refuses to face his audience while speaking, often unwittingly covering his slides, or the whiteboard or whatever visual aid he’s using.

Umberto Unprepared: Umberto likes to wing it, but unfortunately ends up crashing every time. He never prepares for his presentations, and it invariably shows right from his starting stutter to his final fumble.

Oscar Overtime (Thomas Too-much): Oscar is in some ways the extreme opposite of Umberto - he prepares way more material than he has time to deliver. Consequently he ends up going over his allotted time. He’s mastered the art of ignoring frantic signals from meeting moderators and cues from annoyed audiences. He’s prepared all that wonderful material and he’s going to deliver it (all), come what may.

Mike Microphone-Muddler: You’ll hear about half of Mike’s presentation. Unfortunately, it’s impossible to predict which parts of his talk you’ll hear because he keeps drifting in and out of microphone range at random.

No doubt, there are many others I’ve missed in this short list of soporific speakers. I welcome further contributions to the list through your comments.

Some weeks ago I played table tennis , or ping-pong as North American residents know it, for the first time in many years.  The occasion was brought about by a comprehensive power failure in the building I work in. The UPS held up for a half hour or so, giving our ops mob just enough time to notify users and shutdown servers gracefully. That done, all we could do was to wait for the guys at the power company to do their thing.

Deprive a bunch of IT folks of their computers and they’ll soon start inventing other means of entertainment. Sure enough, within minutes someone suggested improvised table tennis, to be played on the lunch room table with CD cases as racquets and printer toner cartons, lined up end-to-end, serving as a rather wide net. We played several rounds of single-point games, with the loser handing the CD case to the first person on the queue (by this time a large queue had formed since no one had anything better to do). 

Whilst engaged in a particular long rally against a worthy opponent from helpdesk, it occurred to me that table tennis rallies are a bit like dealing with clients. Allow me to explain:  the aim of the game - table tennis, not consulting (although some practitioners may consider the latter a game as well) - is to lob or smash or return the ball in any way to the other court as snappily as one’s ability permits.

“And what does this have to do with consultants dealing with clients?”, I hear you ask.

Well, consultants are generally engaged to provide a service in return for which they are paid, often by the hour or some multiple thereof. Given that consultants bill by time, it behooves them to respond to all client queries in a timely manner.

If you are a consultant, your clients should never be left wondering about when they might expect a response from you.  If there’s any waiting to be done, be sure it’s you who is doing the waiting. Snappy, accurate responses to client queries are of paramount importance. As in the case of table tennis, the ball should as far as possible be in their court, not yours.