16 March 2010

Defending your position

Posted by

Today I had a meeting where a project stakeholder kept on highlighting additional things for us to do.  My instinct is to justify that our existing plan is fine and that his concerns are not a priority.

Of course that instinct is wrong, and I know not to follow it, even though I can still sometimes be drawn into arguments.

I've seen it before with 'masterful programme directors'  doing document reviews and PIRs.  It is simply hard to let feedback wash over you without you wanting to justify yourself.

Of course the substance of the comments are secondary.  And while they may be relevant and important or they may be totally irrelevant you are not going to be able to assess it at the table.

Even more importantly, you'll damage your relationship with the people giving feedback.  They are doing you a favour by offering your their insight. Be gracious under pressure.  You never now what you'll discover.
Labels:

3 comments:

  1. Hi Craig! This is exactly how I feel, when I review something with users and stakeholders. When I get to the meeting I try to appreciate both positive and negative feedback, because it helps make my deliverables better. I note all the items raised and address them later, when I had enough time to assess them -- as you say, doing this right at the table is a bad idea.

    I summarized of my experience with getting feedback from users some time ago. Some of those idea, I believe, are also applicable to other stakeholders as well.
    ReplyDelete
  2. Hey Craig, very true observation. Its hard when we receive feedback and every part of you is screaming "look at yourself!" The higher road (if thats the right way of putting it) is often the best taken.
    ReplyDelete
  3. I have no position to defend... on a project, we all want the same thing or it won't work.

    Your example ",... a project stakeholder kept on highlighting additional things for us to do".... things were not in the plan? not in the agreed project scope? The response does not need to invoke a defence. It is "adding things will take us over budget and/or make us miss the target date? Is that what you want for the project?"

    If the stakeholder has the authority to want and get this, that is fine. If not, they have to ask the person who has the authority, because the team doesn't.

    Yes, you have to listen, but its not about you, its about the project. That way you can keep your sanity!
    ReplyDelete

Subscribe to: Post Comments (Atom)

Popular Posts

  • What is Project Scope? What should it be?
    I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
  • User Story Template
    Due to popular demand I have aggregated some information on User Stories and created a simple template.  If you feel this would be useful to...
  • Change Request template
    Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
  • BCS forum on "Making Projects Work"
    You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
  • PDMs - Precedence Diagram Method
    The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
  • Snowbird; Agile 2011 discussion on the BA
    In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
  • Email, Whiteboards and Well-Caffeinated Wits
    This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
  • 7 Requirements Analysis techniques
    In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
  • An Introduction to Stakeholder Management
    The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
  • The V-Model: Table of Contents
    I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...