Archive for the ‘Communication’ Category
Managers aren’t good at listening
Are managers good listeners? This is the question Patrick Barwise and Sean Meehan address in a note published in the April 2008 issue of the Harvard Business Review. The research conducted by Barwise and Meehan indicates that managers tend to overrate themselves on their own openness to frank communication; the gap in self-perception being greatest when the views expressed are contrary those held by the manager. This conclusion is based on 360 degree surveys of more than 4000 US managers across a range of industries and functions.
The authors believe there are two factors at work here. Bosses tend to:
- Overestimate their openness to contrary views, as indicated by the wide differences between self evaluations and those of colleagues.
- Underestimate the extent to which the manager-managed relationship hinders their subordinates from communicating openly. That is, subordinates fear reprisals of some kind if they are the bearers of bad news or contrary views. The authors reckon this happens because bosses often unknowingly send out subtle signals discouraging their subordinates from speaking openly.
To get around this, they suggest that:
- Managers should assume they are less open to frank discussion than they think they are.
- Organisations should use 360 degree surveys specifically targeted to uncovering communication issues. They reckon that bad managers, when confronted with real data may be more open to changing their ways (Good luck with that, I say).
There’s no doubt (to me, at any rate) that Barwise and Meehan are right in their observations about managerial openness to frank communication . Most of us – managers or not – don’t like to be contradicted, and that’s no surprise.
On the other hand, I’m not so sure about their recommended solution. In my opinion fixes at the individual level, such as they suggest, will not work. I believe open communication needs to be fostered at the organisational level for it to permeate right through the corporate hierarchy. Put differently, it is an issue of organisational culture rather than management. Some workplaces have a culture conducive to open communication; others don’t. Those that don’t would not be able to fix the problem by confronting managers with the results of 360 degree surveys (or any other data for that matter). Given the anti-communication culture of the organisation, the said managers would simply deny there’s a problem and worse, may even confront those who they think are responsible for the negative feedback. In fact, because of the latter, such surveys may not even indicate there’s a problem as subordinates would not risk saying what they really think.
I’m interested in knowing what you think about this. Let me know via your comments.
Great expectations and how to manage them
Many project management books contain a section or two on managing stakeholder expectations. The emphasis in most of these tomes tends to be on the bureaucratic aspects of the process – developing stakeholder management plans or getting the project scope statement signed off, for example. Although documents and signatures may be useful in proving that you’ve performed your duties with due diligence (aka CYA), they don’t guarantee stakeholder satisfaction. Despite reams of documentation, a good number of projects are deemed failures because of a mismatch between stakeholder expectations and completed deliverables. I’d go so far as to say that chronic project failure is one of the main reasons why many corporate IT departments get a bad rap.
The root of the problem, in my opinion, is that documented requirements very often do not reflect what a client really wants. It is impossible to get a comprehensive view of client requirements in a limited number of analysis sessions. This difficulty is particularly acute when one tries to document all requirements in one go, as is the case when a waterfall development methodology (also known as Big Design Up Front or BDUF) is used. It is well known that Iterative / Incremental methodologies are better because they ensure that requirements are reviewed and revised several times in the development cycle. Incidentally, this article by Joe Marasco has an excellent, visual explanation of why iterative development is superior to BDUF. Despite this being common knowledge, many corporate IT departments remain stuck under the waterfall. Why this is so is a topic for another post – I’ll just take it as a given here. However, consequent stakeholder dissatisfaction is one of the major reasons why these departments have low credibility within the organisations they serve.
So what can be done about this?
The two-word answer: better communication.
The one-sentence answer: adapt flexible stakeholder management practices from the Iterative/Incremental world and integrate them into your BDUF approach.
The longer answer:
Iterative/Incremental approaches mandate regular meetings between stakeholders and project team members. Consequently these methodologies have stakeholder management built in, as opposed to BDUF approaches which don’t require regular interactions. So when using BDUF methodologies one has to work doubly hard at communicating with stakeholders. When doing so, it is a good idea to adapt practices from Iterative/Incremental approaches and integrate them into your development methodology. In particular, the following points are worth considering:
- Frequent feedback: You don’t need to schedule formal meetings to give people status updates or feedback. Wander over to their office to have a chat and give them an update. If you make a habit of this, you may even find that formal meetings are required less often.
- Frequent delivery (or demos): Although BDUF methods appear to preclude frequent delivery (as opposed to Iterative techniques, which mandate frequent releases), it is often possible to show users work in progress. Schedule informal demos of work in progress where a developer shows end users the current state of the product. By doing so, you may get feedback early enough to do something about it. It’s no good having users complain about the user interface at the final demo.
- Flexible attitude: Yes, I know, your requirements are frozen (the users have signed off on them, after all). However, if you can accommodate changes, it is best that you do (via whatever change control process you have). A blanket, “Next phase” response to all change requests will only annoy your clients. A flexible, can-do attitude will go a long way in getting users “on your side”. Once they see that you do your best to help them, they’ll (usually) reciprocate by not asking you for the moon. Further, on the rare occasions that you turn them down, they’ll (generally) understand that you’re doing so for good reasons.
- Present alternatives when saying no: This is important. If you do have to say, “No” to a user request, try to present a viable workaround or alternative. Often, a well thought out alternative may be more than enough to satisfy the user. Besides, it also gives the user a sense that you are working with them to solve their problems, and not off on your own trip building something that is divorced from their needs.
That’s it. I know, when you look at the list the points seem pretty obvious. However, they are hard to apply in practice – not just because of recalcitrant users, but also due to the numerous constraints on project teams operating in BDUF environments. In practice you’ll also find that these techniques work better on some projects than others – mainly because of differences in user attitudes.
Everyone has great (or should I say, inflated) expectations from things to come. This invariably leads to disappointment in the end. A good part of managing users is to make their expectations more realistic rather than lowering them. The best way to do this is by involving users as much as possible in the development process. This essentially is what Incremental/Iterative and Agile techniques advocate. BDUF practitioners – which include many corporate IT development teams – should take a leaf from their book.
Reviewing documentation on a work day evening
With apologies to Robert Frost (and a colleague who shall remain nameless).
Whose work this is I think I know.
He hasn’t done a good job though.
He will not see me over here,
reading his drivel pure as snow.
The cleaners must think it queer
that I’m still working, though midnight’s near.
Between you and me – it’s late,
on the darkest night of the year.
I give my poor head a shake,
and ask, “Why so many mistakes?”
The only other sound’s the sweep
of the vacuum cleaner’s swift intake.
Slumber beckons, long and deep,
but I have this job to keep,
And files to go before I sleep,
And files to go before I sleep.
Eight to Late 