Comments on: 10 Ways to Communicate More Effectively on IT Projects

By: Jerry Granton

Jerry Granton — Tue, 13 Nov 2012 06:31:14 +0000

I think you hit the nail on the head with your post.

By: Laura (Brandau) Brandenburg

Laura (Brandau) Brandenburg — Sun, 13 Dec 2009 16:38:23 +0000

Hi Richard,
I am a strong proponent of leading by example. Establish a strong set of best practices for the meetings that you are responsible for first. Then begin asking questions (behind the scenes) to help others follow your lead. You might also consider pulling together information on how the improperly planned meetings impact your team or productivity. Numbers and waste can make a strong case for better meetings.
Laura

By: Richard Ranieri

Richard Ranieri — Sat, 12 Dec 2009 18:04:01 +0000

Here’s a question, how do you get “the business” to follow these guidelines? I can’t begin to count the number of meetings I’ve been asked to attend where there was no previously posted agenda, the meeting coordinator arrives late, the wrong individuals were invited. I would say that in the last three years I have attended one or two meetings that were well planned, efficient and effective.

By: Laura (Brandau) Brandenburg

Laura (Brandau) Brandenburg — Wed, 02 Dec 2009 13:28:11 +0000

Steve, thanks for all the great feedback and info. Great comment that really adds to the post. Regarding #1, I hear this a lot from BAs — that they are typically brought in after the problem has been “solved”. I feel fortunate that’s not been my experience, but I think I also create some opportunities here through digging. If I start to get conflicting requirements or see people having trouble prioritize, then I know we need to clarify the problem together as a way forward.

By: Steve Jones

Steve Jones — Tue, 01 Dec 2009 16:54:33 +0000

For some strange reason, #1 – problem identification, seems to be the one that it investigated the least on most of the projects I have been assigned to. By the time I am on a project, the solution has already been identified even though the requirements have yet to be developed.

#6 usually has a way of working things out when FOOD is the intermediary. Trouble with driving directions – give food landmarks. Disagreement between project members – create an afternoon coffee/snack break to work out issues and promote communication.

As for #5 – share business context with your technical team, I couldn’t agree more. If you can include some measure of both technical and business information into the documents (tech for BRD, business for FSD,SRD), you’d be surprised at how that additional information can be useful to the other parties. Sometimes that extra information provides the perfect amount to eliminate confusion and help with understanding… business context for the techs can often lead to the delivery of a better solution than originally planned because now they see “what” AND “why” and do something unexpected… build capability/expansion options because they see it will probably be needed in the future, with only a small (2-5%) variance from what was originally planned.

One addition to the meeting Agenda – including the meeting logistics within the original message. If you can find the time on everyone’s calendars but don’t yet have a room or teleconference #, don’t send it until you do because people don’t always process the follow ups with that info if separate and begin to wonder where/how the meeting is going to happen. In my case, I had extended a holiday break with one extra day knowing there was an early morning meeting upon my return. I tentatively accepted because the logistics info was not included and stated if it wasn’t finalized prior to end of day, my attendance should not be expected. Glad I did because the info never came in and traffic delays made getting to the meeting impossible – and with no call in info available, the meeting was missed entirely.