<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Responsibility vs. Authority</title>
	<atom:link href="http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/feed" rel="self" type="application/rss+xml" />
	<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html</link>
	<description>Management, especially good management, is hard to do. This blog is for people who want to think about how they manage people, projects, and risk.</description>
	<lastBuildDate>Tue, 16 Mar 2010 19:31:52 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Arley McCormick</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-64066</link>
		<dc:creator>Arley McCormick</dc:creator>
		<pubDate>Tue, 22 Dec 2009 15:14:43 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-64066</guid>
		<description>Need a definition of Authority. If your a project lead it is often assumed you make decisions within a framework expected of the company. Most organizations are matrix&#039;s of capability allocated based on some sort of priority. If you can&#039;t establish the priority that eveyone follows you don&#039;t have authority. And, if office politics is the only way you can accomplish the project that chances are it is doomed to fail.</description>
		<content:encoded><![CDATA[<p>Need a definition of Authority. If your a project lead it is often assumed you make decisions within a framework expected of the company. Most organizations are matrix&#8217;s of capability allocated based on some sort of priority. If you can&#8217;t establish the priority that eveyone follows you don&#8217;t have authority. And, if office politics is the only way you can accomplish the project that chances are it is doomed to fail.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Chermside</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-281</link>
		<dc:creator>Michael Chermside</dc:creator>
		<pubDate>Wed, 15 Feb 2006 21:40:15 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-281</guid>
		<description>I fully agree that most of the time you should simply act as if you had the authority, because it&#039;s necessary for you to accomplish your responsibility. However, there is an important exception that I encounter fairly often: when the authority is needed specifically and officially belongs to someone else. If the rules say that the &quot;Project Senior Supplier&quot; has to sign off on any change to delivery dates, then no matter how vital it is to change the delivery date, you can&#039;t do it when your title is &quot;Project Manager&quot;.
My solution in these cases is to share the responsibility. I will usually try to lay out, often in writing, a proposal for exactly how to solve the problem. (For example, &quot;Requirements have been changed; we&#039;ve negotiated the schedule and everyone agrees a 1 week slip is a minimal but achievable accomodation; I propose we change the delivery date to May 12.&quot;) Then I will send it to the person who has the authority. I&#039;ll try to convince them, but if I have any doubts or am concerned that they&#039;ll be &quot;too busy to get to it&quot;, then I will ALSO transfer some of the responsibility as well. For example, I might add this note: &quot;Since development on the changes is already underway, failing to adjust the date could affect the project risk. Thus, I will add &#039;Date adjustment for new requirements&#039; as an entry on the risks list until the requirements and dates are back in synch with each other. I will list you as the actionable party on that risk.&quot;
-- Michael Chermside</description>
		<content:encoded><![CDATA[<p>I fully agree that most of the time you should simply act as if you had the authority, because it&#8217;s necessary for you to accomplish your responsibility. However, there is an important exception that I encounter fairly often: when the authority is needed specifically and officially belongs to someone else. If the rules say that the &#8220;Project Senior Supplier&#8221; has to sign off on any change to delivery dates, then no matter how vital it is to change the delivery date, you can&#8217;t do it when your title is &#8220;Project Manager&#8221;.<br />
My solution in these cases is to share the responsibility. I will usually try to lay out, often in writing, a proposal for exactly how to solve the problem. (For example, &#8220;Requirements have been changed; we&#8217;ve negotiated the schedule and everyone agrees a 1 week slip is a minimal but achievable accomodation; I propose we change the delivery date to May 12.&#8221;) Then I will send it to the person who has the authority. I&#8217;ll try to convince them, but if I have any doubts or am concerned that they&#8217;ll be &#8220;too busy to get to it&#8221;, then I will ALSO transfer some of the responsibility as well. For example, I might add this note: &#8220;Since development on the changes is already underway, failing to adjust the date could affect the project risk. Thus, I will add &#8216;Date adjustment for new requirements&#8217; as an entry on the risks list until the requirements and dates are back in synch with each other. I will list you as the actionable party on that risk.&#8221;<br />
&#8211; Michael Chermside</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Markus Eiber</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-280</link>
		<dc:creator>Markus Eiber</dc:creator>
		<pubDate>Sat, 04 Feb 2006 00:12:49 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-280</guid>
		<description>While people (leaders) taking authority may advance a project, it may also be a source for team conflicts, in the case that your move towards authority isn&#039;t respected. Naturally, there will very often be competition and as a consequence you might end up with a team member being frustrated or even refusing to accept your new authority. How do you  handle such a conflict?</description>
		<content:encoded><![CDATA[<p>While people (leaders) taking authority may advance a project, it may also be a source for team conflicts, in the case that your move towards authority isn&#8217;t respected. Naturally, there will very often be competition and as a consequence you might end up with a team member being frustrated or even refusing to accept your new authority. How do you  handle such a conflict?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Gibbs</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-279</link>
		<dc:creator>Ed Gibbs</dc:creator>
		<pubDate>Thu, 02 Feb 2006 09:09:19 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-279</guid>
		<description>I&#039;d have to say that I&#039;ve always assumed I had to take the authority to move a project forward, and I&#039;ve rarely had the official authority to do so.  So like you I&#039;ve done a lot to keep relationships with people open so they can help me move around roadblocks.
My default is to try to play nice and gently nod the project along, but if someone is just being a big obstacle I go ahead and challenge them directly become a very squeaky wheel.  Life is short, I&#039;d rather make an impact now then just sit around collecting a paycheck and moaning about how that&#039;s just the way it is at Company X.</description>
		<content:encoded><![CDATA[<p>I&#8217;d have to say that I&#8217;ve always assumed I had to take the authority to move a project forward, and I&#8217;ve rarely had the official authority to do so.  So like you I&#8217;ve done a lot to keep relationships with people open so they can help me move around roadblocks.<br />
My default is to try to play nice and gently nod the project along, but if someone is just being a big obstacle I go ahead and challenge them directly become a very squeaky wheel.  Life is short, I&#8217;d rather make an impact now then just sit around collecting a paycheck and moaning about how that&#8217;s just the way it is at Company X.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: matt</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-278</link>
		<dc:creator>matt</dc:creator>
		<pubDate>Thu, 02 Feb 2006 06:03:27 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-278</guid>
		<description>I agree that many young managers do not assume and/or take authority. I&#039;ve been guilty of it myself. But, what about regarding people? I&#039;ve managed many projects where the people &quot;working for me&quot; didn&#039;t really work for me. Luckily, most of the people that have worked for me have been good. However there have been a few that weren&#039;t and when it really came down to it, I was stuck. Talking with the individual didn&#039;t help - they knew I didn&#039;t have any authority. When I approached management about making a change there was always a reason why we had to &quot;make it work&quot;. Making it work resulted in me working long hours to complete the project.</description>
		<content:encoded><![CDATA[<p>I agree that many young managers do not assume and/or take authority. I&#8217;ve been guilty of it myself. But, what about regarding people? I&#8217;ve managed many projects where the people &#8220;working for me&#8221; didn&#8217;t really work for me. Luckily, most of the people that have worked for me have been good. However there have been a few that weren&#8217;t and when it really came down to it, I was stuck. Talking with the individual didn&#8217;t help &#8211; they knew I didn&#8217;t have any authority. When I approached management about making a change there was always a reason why we had to &#8220;make it work&#8221;. Making it work resulted in me working long hours to complete the project.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: matt</title>
		<link>http://jrothman.com/blog/mpd/2006/02/responsibility-vs-authority.html/comment-page-1#comment-277</link>
		<dc:creator>matt</dc:creator>
		<pubDate>Thu, 02 Feb 2006 06:01:36 +0000</pubDate>
		<guid isPermaLink="false">http://jrothman.com/blog/mpd/?p=8082#comment-277</guid>
		<description>I agree that many young managers do not assume and/or take authority.  I&#039;ve been guilty of it myself.  But, what about regarding people?  I&#039;ve managed many projects where the people &quot;working for me&quot; didn&#039;t really work for me.  Luckily, most of the people that have worked for me have been good.  However there have been a few that weren&#039;t and when it really came down to it, I was stuck.  Talking with the individual didn&#039;t help - they knew I didn&#039;t have any authority.  When I approached management about making a change there was always a reason why we had to &quot;make it work&quot;.  Making it work resulted in me working long hours to complete the project.</description>
		<content:encoded><![CDATA[<p>I agree that many young managers do not assume and/or take authority.  I&#8217;ve been guilty of it myself.  But, what about regarding people?  I&#8217;ve managed many projects where the people &#8220;working for me&#8221; didn&#8217;t really work for me.  Luckily, most of the people that have worked for me have been good.  However there have been a few that weren&#8217;t and when it really came down to it, I was stuck.  Talking with the individual didn&#8217;t help &#8211; they knew I didn&#8217;t have any authority.  When I approached management about making a change there was always a reason why we had to &#8220;make it work&#8221;.  Making it work resulted in me working long hours to complete the project.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
