Archive for the ‘Communication’ Category
Solvitur ambulando
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.
Obstacles to project communication
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.
Positive negatives
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!”1. Unfortunately, this trait doesn’t endear him to the folks upstairs2, and a few such refusals soon translate into a company-wide negative perception of the entire IT crew.
Now, as some say, perception is reality3. 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:
1 Some members of this mob are known to issue relatively verbose refusals such as, “No, that’s impossible because <insert random reason here >”.
2 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.
3 See this post and the accompanying discussion for an interesting, if somewhat philosophical, counter-view on perception and reality.
Eight to Late 