Communicating for results – consider your audience

Once upon a time:

  • I had a manager who attested that she was a good communicator – it was just that everyone else was a bad listener.  And then I tendered my resignation.
  • I had a colleague that claimed that she wanted to ensure everyone was having a good time – and then proceeded to order food for all of us based on what she thought we would like.
  • I worked with an organization that were making major changes to how they provisioned service based on recommendations from a book that the CIO loved.  They saw multiple “shadow IT” projects, groups, and employees pop up shortly thereafter.

It always amazes me that people claim to be good communicators but do not understand what they are trying to achieve.  I’ve asked some folks what they were trying to achieve when planning strategic communications, and the answer that I received most often was “to tell people what I think they need to know”.   It is staggering how little consideration is given to the audience. Read more of this post

The Everest Method – How Clients, Project Managers, and Delivery Resources can ensure project success

While sitting and preparing T4s for my company a short while ago, I got quite distracted and ended up following some links through to The Shared Services Canada website, specifically a publication on “What prevents large IT projects from being successful?

The article synthesizes a large amount of very valid points from separate project audits, but specifically does not mention “clients not understanding their own needs.”  This is especially disconcerting as technology projects start to expose more and more of the art of the possible to organizations.

In my experience, some service providers or internal IT departments will respond to uncertainty by tightly scoping what is to be delivered; whereas others will propose what the client seems to want and then submit multiple change orders along the process.  Some service providers may further turn to Agile product management, employing a “show early, show often” tactic (often with limited success based on the usual hard financial and schedule metrics of project – source 1 source 2 source 3 – but increased quality/user satisfaction success – source 1 source 2 source 3) to encourage clients to not focus on the cost, but rather the quality, of the product.

Regardless of the approach, the onus is not only on the external service provider to ensure project success (cost, quality, and schedule), but is on the owning organization as well.  So for organizations that are used to the design-build process, how can they successfully engage external service providers? Read more of this post