<?xml version="1.0" ?>
<rss version="2.0">

<channel>
<title>ProjectManagement.com</title>
<description>IT Project Management for project managers</description>
<link>http://www.projectmanagement.com</link>
<copyright>Copyright: (C) 2013 projectmanagement.com</copyright>
<lastBuildDate>Sat, 18 May 2013 09:00:00 GMT</lastBuildDate>
<image>
<title>ProjectManagement.com</title>
<url>http://www.projectmanagement.com/design/logo.gif</url>
<link>http://www.projectmanagement.com</link>
</image>

<item>
<title>The Path to the PMP (Part 4)</title>
<description>In the journey to PMP fitness, you have taken three decisive steps. But many PMs have not had the opportunity to participate in a suite of courses where most knowledge areas are explored from a combined approach of PMI theory and real-world application. While this can put you at a real disadvantage, it&apos;s still possible to be successful. In out latest installment, we cover Project Integration Management.</description>
<link>http://www.projectmanagement.com/articles/278701/The-Path-to-the-PMP--Part-4-</link>
<pubDate>Wed, 15 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Topic Teasers Vol. 9: Story Points or Hours?</title>
<description>&lt;i&gt;&lt;b&gt;Question:&lt;/b&gt; My team prefers to work in Story Points, but it sometimes becomes hard to deal with the realities of how to estimate a first iteration and how to deal with the availability of the team members. How do experienced agile teams handle these realities?&lt;/i&gt;
&lt;table style=&quot;margin-left:20px;&quot; border=0&gt;
&lt;tr&gt;&lt;td width=&quot;10&quot; align=&quot;right&quot; valign=&quot;top&quot;&gt;A.&lt;/td&gt; &lt;td&gt;If you want to be agile, you must estimate in Story Points. Nothing else will really work for a team once they begin to do the work of the project.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td width=&quot;10&quot; align=&quot;right&quot; valign=&quot;top&quot;&gt;B.&lt;/td&gt; &lt;td&gt;Neither is the correct approach. Estimate your Product Backlog in Ideal Hours, and then they will transfer over easily to the iteration work of the team.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td width=&quot;10&quot; align=&quot;right&quot; valign=&quot;top&quot;&gt;C.&lt;/td&gt; &lt;td&gt;If you create software, use Story Points. If you use agile for any other type of project, estimate in work hours, which you can input into MS Project.&lt;/td&gt;&lt;/tr&gt;
&lt;tr&gt;&lt;td width=&quot;10&quot; align=&quot;right&quot; valign=&quot;top&quot;&gt;D.&lt;/td&gt; &lt;td&gt;Use Story Points for the Product Backlog, but actual hours for the Iteration Backlog.&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;
&lt;/blockquote&gt;</description>
<link>http://www.projectmanagement.com/articles/278710/Topic-Teasers-Vol--9--Story-Points-or-Hours-</link>
<pubDate>Wed, 15 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>What You Should Know About Kanban (Part 3)</title>
<description>If Kanban works well on specific software projects, can it be scaled to facilitate Lean throughout an organization? This article will look at how Kanban can be thought of as a general purpose change management approach for your organization.</description>
<link>http://www.projectmanagement.com/articles/278696/What-You-Should-Know-About-Kanban--Part-3-</link>
<pubDate>Wed, 15 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Keeping the Schedule on Track</title>
<description>If the schedule only exists to track what happened, it is a fairly useless tool. It will be glad to talk to you about the project and tell you how horrible things are, but that is not what project managers need. Here are some ideas for using the schedule to help the project instead of just using it to document failure.</description>
<link>http://www.projectmanagement.com/articles/278702/Keeping-the-Schedule-on-Track</link>
<pubDate>Wed, 15 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Why Giving Up Control is Good for Your Methodology...and Your Projects</title>
<description>If we want better projects, we need to be better at our project management. The question that remains, however, is this: Is consistency and formality the path to get there? Is promoting and demanding adherence to a common process what is required to get to &quot;better&quot;? Here, the evidence is mixed.</description>
<link>http://www.projectmanagement.com/articles/278686/Why-Giving-Up-Control-is-Good-for-Your-Methodology---and-Your-Projects</link>
<pubDate>Mon, 13 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Agile: What&apos;s in it for the Project Manager? (Part 1)</title>
<description>Making a transition from what you&apos;re currently doing to an effective agile process is a project in itself--but it can easily be worth it. There are no guarantees, but let&apos;s look at what we can gain by adjusting our approach...</description>
<link>http://www.projectmanagement.com/articles/278619/Agile--What-s-in-it-for-the-Project-Manager---Part-1-</link>
<pubDate>Thu, 09 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Agile: What&apos;s in It for the Project Manager? (Part 2) </title>
<description>Making a transition from what you&apos;re currently doing to an effective agile process is a project in itself--but it can easily be worth it. Let&apos;s look at what we can gain by adjusting our approach--our concluding installment looks at interpreting requirements and tracking progress, and offers some further caution and advice.</description>
<link>http://www.projectmanagement.com/articles/278621/Agile--What-s-in-It-for-the-Project-Manager---Part-2--</link>
<pubDate>Thu, 09 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>How to be Extraordinarily Agile</title>
<description>On an agile project, we often must accomplish the extraordinary. Yet how can we do so when we must work with such...ahem...ordinary people? Here are some suggestions for helping your group of ordinary individuals to accomplish the extraordinary on your agile project.</description>
<link>http://www.projectmanagement.com/articles/278629/How-to-be-Extraordinarily-Agile</link>
<pubDate>Thu, 09 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>How to Adapt Leadership for Evolving Teams</title>
<description>There is no exact science for people. Just as our project processes should be context-specific, so too should our team processes. Depending on whether your team is brand new, establishing itself or stable, the way we interact as managers and leaders should be tailored to fit the circumstances. Here are some pointers.</description>
<link>http://www.projectmanagement.com/articles/278630/How-to-Adapt-Leadership-for-Evolving-Teams</link>
<pubDate>Thu, 09 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>What Do Your PMs Think of Your PMO?</title>
<description>What is your PMO&apos;s reputation among the PMs it serves? There could be a lot of distrust. Through experience, one manager discovered some potential problem areas that you may want to look at in your own organization.</description>
<link>http://www.projectmanagement.com/articles/278614/What-Do-Your-PMs-Think-of-Your-PMO-</link>
<pubDate>Tue, 07 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Bridging the Gap Between Understanding and Experience</title>
<description>How does a project manager bridge the gap between understanding and experience? For PMs who are starting out in the field or who haven&apos;t mastered everything under the sun, it can always be beneficial to gain practical experience in different areas so that they have a better understanding of how things should be done.</description>
<link>http://www.projectmanagement.com/articles/278604/Bridging-the-Gap-Between-Understanding-and-Experience</link>
<pubDate>Mon, 06 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Should Technology and Process Coexist?</title>
<description>With the ever increasing use of technology, how are processes impacted? Our writer feels that technology should be an overlay to the process work--we should start with a solid process and then look for ways that technology could make life easier in the execution of the process. But a colleague doesn&apos;t agree...</description>
<link>http://www.projectmanagement.com/articles/278601/Should-Technology-and-Process-Coexist-</link>
<pubDate>Mon, 06 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>How Emergency Response Helps Project Execution</title>
<description>While many projects may not have to adopt the elements of the Federal Incident Command System, some are set up to resolve a certain time-bound resolution of organizational priorities and can reap the benefits. </description>
<link>http://www.projectmanagement.com/articles/278602/How-Emergency-Response-Helps-Project-Execution</link>
<pubDate>Mon, 06 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>Why You&apos;re Confusing Frameworks with Methodologies</title>
<description>It&apos;s surprising how many project managers don&apos;t know the difference between a framework and a methodology. It&apos;s time to clear the air and clarify the differences.</description>
<link>http://www.projectmanagement.com/articles/278600/Why-Youre-Confusing-Frameworks-with-Methodologies</link>
<pubDate>Mon, 06 May 2013 04:00:00 GMT</pubDate>
</item>


<item>
<title>The Postmortem Process</title>
<description>Unrehearsed players executing spontaneous postmortems will not reap the full benefits, but cultivated regimens can enable even casual players to consistently succeed and draw expected results in ad hoc postmortems. If you&apos;re in a PANIC, maybe it&apos;s time to get PACIFIC...</description>
<link>http://www.projectmanagement.com/articles/278404/The-Postmortem-Process</link>
<pubDate>Wed, 01 May 2013 04:00:00 GMT</pubDate>
</item>



</channel>
</rss>

