<?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; Prioritization and Selection</title>
	<atom:link href="http://blog.effectiveitgroup.com/tag/prioritization/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>Research for book: How do you balance resources?</title>
		<link>http://blog.effectiveitgroup.com/2009/09/research-for-book-how-do-you-balance-resources/</link>
		<comments>http://blog.effectiveitgroup.com/2009/09/research-for-book-how-do-you-balance-resources/#comments</comments>
		<pubDate>Wed, 16 Sep 2009 00:23:51 +0000</pubDate>
		<dc:creator>Dave B</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[Capacity Planning]]></category>
		<category><![CDATA[Prioritization and Selection]]></category>
		<category><![CDATA[Resource Management]]></category>
		<category><![CDATA[Resource Planning]]></category>

		<guid isPermaLink="false">http://blog.effectiveitgroup.com/?p=100</guid>
		<description><![CDATA[<p>Over the past few years I have certainly done my share of pontificating on how to balance staff resources against what seems like unlimited demand from projects (and other quarters). But when the rubber meets the road, we all have to find a way to make it work.</p>
<p> All that pontificating and consulting has lead to [...]]]></description>
			<content:encoded><![CDATA[<p>Over the past few years I have certainly done my share of pontificating on how to balance staff resources against what seems like unlimited demand from projects (and other quarters). But when the rubber meets the road, we all have to find a way to make it work.</p>
<p> All that pontificating and consulting has lead to a request to write a chapter in an upcoming book on this very subject. But before I blindly write based on my experience (and that of my clients), I want to listen.  What works for you? How do you really manage your resource loads? What techniques do you use to attempt to get all the work done without burning out your people?</p>
<p> You may reply to me privately, or share you thoughts in this blog post. And who knows, you may be quoted in the book (with your permission, of course)  <img src='http://blog.effectiveitgroup.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
			<wfw:commentRss>http://blog.effectiveitgroup.com/2009/09/research-for-book-how-do-you-balance-resources/feed/</wfw:commentRss>
		<slash:comments>117</slash:comments>
		</item>
		<item>
		<title>Project Intake: The sales funnel for PMOs</title>
		<link>http://blog.effectiveitgroup.com/2009/05/project-intake-the-sales-funnel-for-pmos/</link>
		<comments>http://blog.effectiveitgroup.com/2009/05/project-intake-the-sales-funnel-for-pmos/#comments</comments>
		<pubDate>Fri, 15 May 2009 23:20:31 +0000</pubDate>
		<dc:creator>Dave B</dc:creator>
				<category><![CDATA[Prioritization and Selection]]></category>
		<category><![CDATA[Initiation]]></category>
		<category><![CDATA[PMO]]></category>
		<category><![CDATA[Portfolio Management]]></category>

		<guid isPermaLink="false">http://blog.effectiveitgroup.com/?p=51</guid>
		<description><![CDATA[Most PMOs I work with face the same problem: too many project requests and not enough time to do them all! I will admit, I've worked with one group that did not have this problem. They have plenty of money and were told that if it's a worthwhile project, there's ample funding and they can hire all the people they need. If you're in that situation, no need to read on. Rest assured - the rest of us are envious!

But, if you're like the other 99% of PMOs in the world, you need a way to manage this onslaught of potential work.

In the sales world, they have what's known as the sales pipeline or sales funnel. This is a process whereby potential opportunities are matured, step by step, to fruition as a completed sale. Along the way, opportunities fall by the wayside. They may not have budget to buy, may not need the products on offer, or just don't have enough interest.

Sales will draw this process as a funnel that has several stages. At each stage, a number of opportunities will fall out of the pipeline. Hence, the funneling effect. They start as opportunities (hey - I've got someone's phone number!), progress to prospects (they actually my call!), become qualified prospects (they have budget!), and finally customers (wow - they actually signed the contract!)]]></description>
			<content:encoded><![CDATA[<p>Most PMOs I work with face the same problem: too many project requests and not enough time to do them all! I will admit, I&#8217;ve worked with one group that did not have this problem. They have plenty of money and were told that if it&#8217;s a worthwhile project, there&#8217;s ample funding and they can hire all the people they need. If you&#8217;re in that situation, no need to read on. Rest assured &#8211; the rest of us are envious!</p>
<p>But, if you&#8217;re like the other 99% of PMOs in the world, you need a way to manage this onslaught of potential work.</p>
<p>In the sales world, they have what&#8217;s known as the sales pipeline or sales funnel. This is a process whereby potential opportunities are matured, step by step, to fruition as a completed sale. Along the way, opportunities fall by the wayside. They may not have budget to buy, may not need the products on offer, or just don&#8217;t have enough interest.</p>
<p>Sales will draw this process as a funnel that has several stages. At each stage, a number of opportunities will fall out of the pipeline. Hence, the funneling effect. They start as opportunities (hey &#8211; I&#8217;ve got someone&#8217;s phone number!), progress to prospects (they actually my call!), become qualified prospects (they have budget!), and finally customers (wow &#8211; they actually signed the contract!)</p>
<p>What if PMOs could have a similar process? What if we had a funnel that allowed us to qualify project ideas step-by-step?</p>
<p><span id="more-51"></span></p>
<p>Currently, most PMOs take an idea and spend a lot of time and money giving it a full analysis before presenting it for final approval. How much time and money could be saved by funneling those ideas through some filters so that only qualified ideas are analyzed?</p>
<p>That&#8217;s the idea behind a Project Intake process. We start with an idea (hey &#8211; let&#8217;s redo the company website!), progress it to a request (here&#8217;s why we should re-do the website. It&#8217;ll pump up revenues!), qualify the request (the scorecard for the website redesign looks good!), create a full-blown business case (wow &#8211; the numbers for this redesign really pan out), then finally it becomes a project (the committee approved the re-design! Hooray!).</p>
<p>To work effectively, this really should be a portfolio process &#8211; not a project management process. Why? Because as we&#8217;re taking requests through the pipeline, they need to be compared to each other and winnowed down to the organizations ability to execute (budget, resources, and skills). By comparing requests as a slate early on, we can narrow down the number of requests that get the full analysis treatment, saving tons of money. By using a funnel approach, we can ensure the outcome is a portfolio of the most worthwhile projects that fit our organization.</p>
<p>So, do you have an effective Project Intake Funnel? If not, contact us. We can help you design one that fits your organization. And we&#8217;ll do so on an advisory basis, which gets the job done for a lot less than a consultant that looks like an FTE taking up desk space!</p>
<p>Just need a scorecard to help with that initial winnowing? We&#8217;ve got a best-practice scorecard that can be used as a starting point! And, of course, we can help you develop one tailor-made for your PMO.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.effectiveitgroup.com/2009/05/project-intake-the-sales-funnel-for-pmos/feed/</wfw:commentRss>
		<slash:comments>44</slash:comments>
		</item>
		<item>
		<title>Project Prioritization: Getting Execs to Pay Attention</title>
		<link>http://blog.effectiveitgroup.com/2009/01/getting-execs-to-pay-attention/</link>
		<comments>http://blog.effectiveitgroup.com/2009/01/getting-execs-to-pay-attention/#comments</comments>
		<pubDate>Thu, 15 Jan 2009 18:11:20 +0000</pubDate>
		<dc:creator>Dave B</dc:creator>
				<category><![CDATA[Prioritization and Selection]]></category>
		<category><![CDATA[Adoption]]></category>
		<category><![CDATA[PMO]]></category>

		<guid isPermaLink="false">http://blog.effectiveitgroup.com/?p=28</guid>
		<description><![CDATA[There seem to be a couple of immutable truths in the PMO world, especially in IT departments. First, there is always more work than can possibly be done. This usually surfaces in the form of an insatiable appetite for projects. Second, no matter how you prioritize the work, someone's going to be unhappy - and they'll try to make your life miserable by becoming the squeakiest wheel in the company.

The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It's great theory, with one major flaw. Those execs don't readily participate. I can't count the number of poorly attended steering committee meetings I've run across. 

So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I've found is what I call "shock therapy for the executive team" . . .]]></description>
			<content:encoded><![CDATA[<p>There seem to be a couple of immutable truths in the PMO world, especially in IT departments. First, there is always more work than can possibly be done. This usually surfaces in the form of an insatiable appetite for projects. Second, no matter how you prioritize the work, someone&#8217;s going to be unhappy &#8211; and they&#8217;ll try to make your life miserable by becoming the squeakiest wheel in the company.</p>
<p>The answer, as we PMO practitioners all know, is to elevate the prioritization decisions up to the company executives. This usually means some sort of cross-functional steering committee or other governing body. It&#8217;s great theory, with one major flaw. Those execs don&#8217;t readily participate. I can&#8217;t count the number of poorly attended steering committee meetings I&#8217;ve run across. The execs either don&#8217;t show or send a lower ranking delegate not empowered to make decisions. Which leaves the steering committee pretty powerless, and results in the CIO once again making the decisions. And once again taking the heat.</p>
<p>So, how do you get these all-too-busy executives to pay attention and take responsibility for prioritization? The best process I&#8217;ve found is what I call &#8220;shock therapy for the executive team&#8221;, and it involves three steps: Presentation, Argument, and Decision Time.<br />
<span id="more-28"></span><br />
Step 1: Present the problem.This is all about making the problem obvious. During one of my CIO stints, we were creating a new IT infrastructure from scratch. This, of course, involved many parallel projects that could not possibly all be run in parallel. So, I formed an project steering committee and invited all the VPs. All but a few sent delegates, and we made no decisions.</p>
<p>Fine. So I put together a picture of the entire architecture, detailed in big blocks the major pieces, there costs, effort, and timelines and presented this big picture to the corporate executive team at the monthly monthly meetings. I showed them the millions in costs, all the projects going live in the same month, and the amount of resources (double what we had on hand) required to get the job done. The CTO, who ran the product development group, took one look and said</p>
<p> &#8221;Dave &#8211; if I were running this, there&#8217;s no way I could do all of this at once. What are you going to do? How will you prioritize this?&#8221;</p>
<p>My response: &#8220;That&#8217;s why I&#8217;m here&#8221;.</p>
<p> </p>
<p>Which lead immediately to Step 2: Argument.</p>
<p>First, the VP of professional services demanded that his CRM piece was critical and had to go live ASAP. To which the VP of Sales argued that if the SFA system wasn&#8217;t put in place first, Sales would get stuck and Services would have nothing to do anyway! As you can imagine, each VP argued for there piece of the pie.</p>
<p>Which finally leads to Step 3: Decision Time.<br />
I&#8217;ve written before about the use of various prioritization tools, such as scorecards, strategic alignment, etc. Here is where those tools finally come into play. They allow the executives, once they settle down, to look at some objective analysis to help them figure out which projects should come first. Whether that importance is based on fit to corporate strategy or critical operational needs, these tools are meant to be informative, not conclusive. You will also want to present any project interdependencies at this stage.</p>
<p>In the case above, the Exec Team quickly realized that some core processes were in dire need of automation, and that the ERP system was also the core of the architecture. Therefore, projects relating to ERP came first. The other VPs then understood why they had to wait. Even better, I was asked to present progress and new initiatives quarterly so we could decide as a body how to proceed. Note that in this case, we never even formed a Steering Committee. The Executive Team ended up taking responsibility directly!</p>
<p>I have seen this process work repeatedly, and the steps to &#8220;shock therapy&#8221; tend to follow the same pattern:</p>
<p>1 -Shock them with the enormity of the problem. And do it with graphics and simple numbers, not long lists of individual projects. If they get lost in the details here you&#8217;ll be back at square one.</p>
<p>2 -Let them argue for a while. As they struggle with the problem they will realize this is way too important to delegate to their underlings, the CIO, or the PMO. They will realize these are truly strategic decisions &#8211; that&#8217;s their job and they know it.</p>
<p>3 -Provide them with the information they need make these decisions. This information varies, of course, by company. So, you&#8217;ll have to work with your Exec Team to figure what information is most effective.</p>
<p>And good luck &#8211; while this is easy to write about, it&#8217;s no cake walk to execute. You&#8217;ll be relying heavily on the relationships you&#8217;ve built with each executive (you have done that &#8211; right?) to see you through this process!</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.effectiveitgroup.com/2009/01/getting-execs-to-pay-attention/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

