<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Lessons from 100 PMOs &#187; PMO Mistakes</title>
	<atom:link href="http://blog.effectiveitgroup.com/tag/pmo-mistakes/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.effectiveitgroup.com</link>
	<description>Real world lessons learned from working with 100+ PMOs</description>
	<lastBuildDate>Tue, 17 Nov 2009 05:01:18 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.3</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Top PMO Mistakes</title>
		<link>http://blog.effectiveitgroup.com/2008/08/top-pmo-mistakes/</link>
		<comments>http://blog.effectiveitgroup.com/2008/08/top-pmo-mistakes/#comments</comments>
		<pubDate>Thu, 07 Aug 2008 23:50:29 +0000</pubDate>
		<dc:creator>Dave B</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[MostPopular]]></category>
		<category><![CDATA[PMO]]></category>
		<category><![CDATA[PMO Mistakes]]></category>
		<category><![CDATA[Project Management Office]]></category>

		<guid isPermaLink="false">http://blog.effectiveitgroup.com/?p=3</guid>
		<description><![CDATA[I was speaking at a SIM (Society for Information Management) event the other night, when the question came up "What's the most common mistake you see PMOs making?". A great question, and a really great blog topic! At EffectiveIT Group, we encounter several PMOs a month, and so we have ample opportunity to see the good, the bad, and the ugly of PMOs. ]]></description>
			<content:encoded><![CDATA[<p><span style="font-size: 8pt; font-family: Arial;">I was speaking at a SIM (Society for Information Management) event the other night, when the question came up &#8220;What&#8217;s the most common mistake you see PMOs making?&#8221;. A great question, and a really great blog topic! At EffectiveIT Group, we encounter several PMOs a month, and so we have ample opportunity to see the good, the bad, and the ugly of PMOs.</span></p>
<p>So, here are my most commonly observed PMO mistakes. Feel free to add your own or comment on these!</p>
<p style="font-size: 8pt; margin: 0in 0in 0in 0.375in; font-family: Arial;"> </p>
<ol>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt;"><span style="font-size: 8pt; font-family: Arial;">PLAYING COP. If there is a common refrain to failed PMOs, this is it. The PMO becomes the &#8220;Methodology Police&#8221; and enforce an often ill-fitted SDLC rigorously. This leads to complaints from project managers at best, and open revolt and ignoring the methodology at worst. Rather than becoming an aid and guide to project managers, and creating consistency in PM practices, this PMO has become the PM&#8217;s worst enemy, loses visibility into the project portfolio, and leaves a bad taste in everyone&#8217;s mouth.<span id="more-3"></span></span></span></div>
</li>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt;"><span style="font-size: 8pt; font-family: Arial;">IMPLEMENTING AN SDLC. OK &#8211; this might sound heretical, but hear me out. I have seen many PMOs implement an SDLC, literally a &#8220;Software Development Life Cycle&#8221;. This is great for the software development team, but drives the infrastructure and process improvement folks nuts! The point here is, one size does not fit all. A better structure is an overall project management framework, with just the basic phases and gates and a few key controlling artifacts (business case, project schedule, status report, etc.). This is sometimes known as a PDLC (Project Development Life Cycle), and many different SDLCs can fit under the framework, tailored to the need of the project type.</span></span></div>
</li>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt;"><span style="font-size: 8pt; font-family: Arial;">NOT IMPLEMENTING A METHODOLOLY. What, am I contradicting myself? Not really. If the PMO does not implement some kind of overarching framework, it cannot create an apples-to-apples view of the projects in the portfolio. Further, federal regulations, especially Sarbanes-Oxley, require methodologies that meet their requirements.</span></span></div>
</li>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt;"><span style="font-size: 8pt; font-family: Arial;">NOT MATCHING DEMAND TO SUPPLY. I&#8217;ve sat in on many a Steering Committee meeting, and the focus is almost always on prioritization. That&#8217;s great, and a good prioritization process results in a good understanding of project demand. But when it comes to deciding how many of the top projects can actually be done, discussion usually turns to pure guess work! &#8211; &#8220;How overloaded is you department, Tom?&#8221;. &#8220;If we take on the top 10, can we handle the load?&#8221; Without a metrics-based understanding of resource capacity, it is impossible to match that wonderfully organized demand with the actual supply of human resources.</span></span></div>
</li>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt;"><span style="font-size: 8pt; font-family: Arial;">NOT LOGGING TIME. This is actually the source of number 4. Without tracking actual time worked on actual projects AND other work, it is impossible to know any department&#8217;s true capacity. Planning, even at the most detailed level, is merely guesswork if it does not involve the feedback loop of actual time.</span></span></div>
</li>
<li>
<div style="margin-top: 0px; margin-bottom: 0px; vertical-align: middle;"><span style="font-size: 8pt; font-family: Arial;">GATHERING UNECCESARY INFORMATION. PMOs are great at gathering all sorts of statistics, from very detailed SDLCs (see number 1 above!). If that information is not used in the decision-making process, why gather it? It just creates an extra burden on the project team without generating any useful result. Example: gathering time data at the detail task level, including sub-day tasks like &#8220;Enter time&#8221;, &#8220;Check email&#8221;, &#8220;Respond to email&#8221;, &#8220;Attend staff meeting&#8221;. These may be useful reminders as tasks, but for planning purposes all we really need to know is how much time each resource is spending performing &#8220;Admin&#8221; tasks.<br />
</span><span style="font-size: 8pt; font-family: Arial;"><br />
That&#8217;s my list for today. I&#8217;m sure you have others to add to the list &#8211; please do! And if you want to hear more on any one of these topics, please let me know. I&#8217;ll try to address it in a future Blog.</span></div>
</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://blog.effectiveitgroup.com/2008/08/top-pmo-mistakes/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

