Random Acts of IT Project Management

Project Management for Information Technology

Bridging the Gap

Posted by iammarchhare on 29 May 2009

This week, we’ve looked at use cases vs user stories, basic abilities for PMs and BA competencies for gathering requirements.  All of these involve in one way or another transforming user requirements into reality.  In “Use Cases and User Stories – Just Degrees of Difference?” we saw that one of the issues with user stories is whether or not the customer has built up “trust” in the process.  I mentioned in “Are You Cut Out to be a Project Manager?” that a PM must be able to bridge people and technology.  And, finally in “Avoiding Project Failure: Gathering Requirements”, we looked at some core competencies for BAs or for PMs filling the role.  All of these involve communication.

I couldn’t help but think of communication when I read “The Role of Agile Advocates” by Lynda Bourne on PMI’s blog.  She writes:

Forget the jargon of “sprints” and “iterations.” Communicate in your stakeholder’s language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?

You know, this has little to do with Agile.  It is good advice always.

I’m of the opinion that all developers should have to either do helpdesk or desktop support starting out.  Why?  Because there is no better way than experience for a developer to get to know how endusers work, how they think and what they want.  You develop a real empathy for them if you care about your job at all.

I learned something early on because of doing desktop support.  I learned that users just want to get their work done.  They don’t care about bits and bytes, routers, packets, objects, classes or any of the other stuff that IT cares about.  They don’t want to learn a new language to talk to you.  All they care about is that their email, spreadsheet, billing or other program isn’t working.  They want it fixed.  I had to learn their language.

Mind you, this does not mean talking down to them.  Some of the people I dealt with were chemists and engineers.  You want to hear jargon?  They will give you jargon!  Don’t even get me started on day traders!  They are from a completely different country!  No, if you talk down to these people, they could put you in your place rather quickly!

Remember, you are rendering a service.  You might have a degree, and you might make more than a burger flipper, but the reality is you are enabling a person/team/company to be more productive.  To achieve that end, you have to be able to communicate, which means listening as well as talking.  You then have to be able to encode and decode the information between a technical core and the business owner/sponsor/customer.

Without communication, nothing else you do as a project manager will be successful.


Sorry, the comment form is closed at this time.

%d bloggers like this: