<?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: Delivering Projects by Managing Ops with a Duty Analyst</title>
	<atom:link href="http://leodesousa.ca/2009/12/delivering-projects-by-managing-ops-with-a-duty-analyst/feed/" rel="self" type="application/rss+xml" />
	<link>http://leodesousa.ca/2009/12/delivering-projects-by-managing-ops-with-a-duty-analyst/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=delivering-projects-by-managing-ops-with-a-duty-analyst</link>
	<description>a practical approach by Leo de Sousa</description>
	<lastBuildDate>Tue, 31 Jan 2012 18:22:34 -0800</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: LeodeSousa</title>
		<link>http://leodesousa.ca/2009/12/delivering-projects-by-managing-ops-with-a-duty-analyst/comment-page-1/#comment-2039</link>
		<dc:creator>LeodeSousa</dc:creator>
		<pubDate>Mon, 21 Dec 2009 02:46:09 +0000</pubDate>
		<guid isPermaLink="false">http://leodesousa.ca/?p=640#comment-2039</guid>
		<description>Johan,

Thank you for the comments and the questions.  I will try to give you more details below.

We implemented the ITIL Incident Management process over 5 years ago. Over that time, we developed a culture of managing operational work via queues.  This was in response to the constant phone calls directed at our technical staff causing constant interruptions and delays in project deliverables. Also our clients complained to us about the inconsistent service they received. Worse we had no way to tell what we were working on to give our clients good answers to their service concerns.  We began by educating our clients and our technical staff that all requests/incidents had to be tracked in our common service desk system. As incidents were categorized by our service desk, they were assigned to team queues.  This was a good start but still caused our technical staff to split their workdays between operational incidents and their project work. 

When we started to think about the Duty Analyst, it was to address complaints from my development team about the interruptions caused by daily operational issues.  We gather monthly to review the queue.  The outgoing duty analyst reports out on how their month went. Next, as a group we review all items in the queue and assign 3 to 6 incidents to the incoming duty analyst.  There is a huge benefit to doing this as a team.  Everyone sees what is in the queue and we all agree on what is a fair workload for the duty analyst.  Since they all know that they will be doing this work, the level of candor and teamwork is really great to see. One of the biggest pluses for the team of 6 developers is knowing they have two months a year of operational work and the rest of the year to work on fun and interesting projects.  It almost sells itself!

If there is anything else I can share with you please let me know.  As a manager of this team, I am completely impressed by how this little change in the way we work has made our team so productive.  That is something really good to celebrate!

All the best, Leo 
@leodesousa</description>
		<content:encoded><![CDATA[<p>Johan,</p>
<p>Thank you for the comments and the questions.  I will try to give you more details below.</p>
<p>We implemented the ITIL Incident Management process over 5 years ago. Over that time, we developed a culture of managing operational work via queues.  This was in response to the constant phone calls directed at our technical staff causing constant interruptions and delays in project deliverables. Also our clients complained to us about the inconsistent service they received. Worse we had no way to tell what we were working on to give our clients good answers to their service concerns.  We began by educating our clients and our technical staff that all requests/incidents had to be tracked in our common service desk system. As incidents were categorized by our service desk, they were assigned to team queues.  This was a good start but still caused our technical staff to split their workdays between operational incidents and their project work. </p>
<p>When we started to think about the Duty Analyst, it was to address complaints from my development team about the interruptions caused by daily operational issues.  We gather monthly to review the queue.  The outgoing duty analyst reports out on how their month went. Next, as a group we review all items in the queue and assign 3 to 6 incidents to the incoming duty analyst.  There is a huge benefit to doing this as a team.  Everyone sees what is in the queue and we all agree on what is a fair workload for the duty analyst.  Since they all know that they will be doing this work, the level of candor and teamwork is really great to see. One of the biggest pluses for the team of 6 developers is knowing they have two months a year of operational work and the rest of the year to work on fun and interesting projects.  It almost sells itself!</p>
<p>If there is anything else I can share with you please let me know.  As a manager of this team, I am completely impressed by how this little change in the way we work has made our team so productive.  That is something really good to celebrate!</p>
<p>All the best, Leo<br />
@leodesousa</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Johan Lindberg</title>
		<link>http://leodesousa.ca/2009/12/delivering-projects-by-managing-ops-with-a-duty-analyst/comment-page-1/#comment-2027</link>
		<dc:creator>Johan Lindberg</dc:creator>
		<pubDate>Sat, 19 Dec 2009 20:52:25 +0000</pubDate>
		<guid isPermaLink="false">http://leodesousa.ca/?p=640#comment-2027</guid>
		<description>Hi Leo,

and thanks for yet another interesting post.

A couple of months ago, I was leading a project team aiming to find a solution to the problem of mixing project and operations work with our limited pool of resources. We ended up suggested something very similar to what you describe (we didn&#039;t call it Duty Analyst though).

Unfortunately no one else thought it was a very good idea. Those of us who worked to produce the suggestion are quite certain that it will pay off rather quickly but we&#039;re stuck at the moment since no one even wants to give it a try even though every one agrees that the way we do it now is really terrible.

Did you sugar coat this in any way to get people to accept spending a whole month doing operations instead of project work?

BR
@johanlindberg</description>
		<content:encoded><![CDATA[<p>Hi Leo,</p>
<p>and thanks for yet another interesting post.</p>
<p>A couple of months ago, I was leading a project team aiming to find a solution to the problem of mixing project and operations work with our limited pool of resources. We ended up suggested something very similar to what you describe (we didn&#8217;t call it Duty Analyst though).</p>
<p>Unfortunately no one else thought it was a very good idea. Those of us who worked to produce the suggestion are quite certain that it will pay off rather quickly but we&#8217;re stuck at the moment since no one even wants to give it a try even though every one agrees that the way we do it now is really terrible.</p>
<p>Did you sugar coat this in any way to get people to accept spending a whole month doing operations instead of project work?</p>
<p>BR<br />
@johanlindberg</p>
]]></content:encoded>
	</item>
</channel>
</rss>

