<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>ProjectConnections</title>
        <description>Resources and Know-How for Project and Product Managers</description>
        <link>http://www.projectconnections.com</link>
        <copyright>2008</copyright>
        <docs>http://blogs.law.harvard.edu/tech/rss</docs>
        <language>en-us</language>
        <lastBuildDate>Tue, 13 May 2008 08:33:02 -0700</lastBuildDate>
        <managingEditor>deanna@projectconnections.com</managingEditor>
        <pubDate>Tue, 13 May 2008 08:33:01 -0700</pubDate>
        <webMaster>erik@projectconnections.com</webMaster>
        <generator>FeedForAll v2.0 (2.0.2.5) http://www.feedforall.com</generator>
        <item>
            <title>Featured Article:  What does &quot;Great PM&quot; leadership look like? by Cinda Voegtli</title>
            <description>I&apos;ve talked in previous articles about aspects of being a great project manager, including what I view as business-oriented leadership: driving forward and leading the team to ensure that a project is launched, planned, and executed with alignment to business goals and customer needs.
&lt;br /&gt;&lt;br /&gt;
I haven&apos;t yet touched much on a different aspect of leadership, which I refer to the &quot;leadership persona&quot; - not just what you do as a leader, but also how you come across to others as you lead the team. Along the line I have heard particular managers labeled as strong leaders based (apparently) on their extroverted motivational styles. Over time I have concluded personally that successful team leadership does not depend on the &quot;rah rah&quot; version of extroverted leadership as a foundational requirement.</description>
            <link>http://blog.projectconnections.com/executive_view/2008/05/what-is-a-great.html</link>
            <guid isPermaLink="false">E9BA08B0-1351-4258-B86A-1BB34E135FC5</guid>
            <pubDate>Tue, 13 May 2008 08:32:30 -0700</pubDate>
        </item>
        <item>
            <title>Featured Article: The Hardest Word in the Project Management Vocabulary by Carl Pritchard</title>
            <description>For project managers, &quot;no&quot; is often the toughest word in the English language to deploy. We often prefer the classic PM strategy of &quot;Yes, but...&quot; as the softer, kinder, gentler alternative. &quot;No&quot; sounds harsh. Uncooperative. It sounds reticent and recalcitrant. It sounds negative. And yet, for many of us, the time has come as professionals to set &quot;yes, but...&quot; aside and venture into the world of &quot;no.&quot;
&lt;br /&gt;&lt;br /&gt;
I say this because I note that with increasing frequency, clients are not taking &quot;yes, but...&quot; as an answer. No sooner do we offer a &quot;yes-we-can-do-that, but-it-costs-you-another-million&quot; response that the customer hears only the first half of the equation. They often seem far more interested in capability than cost.</description>
            <link>http://blog.projectconnections.com/carl_pritchard/2008/05/the-hardest-wor.html</link>
            <guid isPermaLink="false">E6D5F2E5-EC70-49E3-8883-F52F2C543414</guid>
            <pubDate>Tue, 13 May 2008 08:32:29 -0700</pubDate>
        </item>
        <item>
            <title>Leadership and the Project Lifecycle</title>
            <description>This guideline illustrates the evolution of leadership responsibilities throughout those phases. Use it to plan staffing, understand needed skills, and direct the evolution of your own leadership understanding and capabilities.</description>
            <link>http://www.projectconnections.com/templates/detail/leadership-project-lifecycle.html</link>
            <guid isPermaLink="false">A2E7AFD2-602F-4D90-B600-93058C97FC8A</guid>
            <pubDate>Tue, 13 May 2008 08:32:27 -0700</pubDate>
        </item>
        <item>
            <title>Consulting Contract Guidelines</title>
            <description>These contract guidelines and examples can help you set expectations that make sense for your organization, from either end of the consulting relationship. Document your understanding about important subjects like intellectual property, payment terms, and termination agreements before you get started.</description>
            <link>http://www.projectconnections.com/templates/detail/consulting-contract-guidelines.html</link>
            <guid isPermaLink="false">E535A94C-6DFC-4E01-930C-7538A22F0553</guid>
            <pubDate>Tue, 13 May 2008 08:32:26 -0700</pubDate>
        </item>
        <item>
            <title>Status Reports</title>
            <description>Current status reports are good indicator of what matters to your team members, executive and functional. That&apos;s not to say it should be the only or primary metrics for project success, but it&apos;s very likely to be important in any successfully received measurement effort. See some example formats from other organizations.</description>
            <link>http://www.projectconnections.com/templates/detail/project-status-report.html</link>
            <guid isPermaLink="false">75993FE7-F7C2-4A29-9B07-1D25F89CC25D</guid>
            <pubDate>Tue, 13 May 2008 08:32:24 -0700</pubDate>
        </item>
        <item>
            <title>Performance Appraisals</title>
            <description>Measurement of effectiveness on a project is a good motivator only if people are actually getting credit for doing well! One way to build this into your appraisal process (and potentially also get some metrics for project effectiveness in other venues) is described in these guidelines.</description>
            <link>http://www.projectconnections.com/templates/detail/project-performance-appraisal-forms.html</link>
            <guid isPermaLink="false">9DBBDFD3-C1E0-48BE-936A-A41DA944F4CD</guid>
            <pubDate>Tue, 13 May 2008 08:32:23 -0700</pubDate>
        </item>
        <item>
            <title>Requirements and Change Management</title>
            <description>How will the organization measure and account for change requests, quality, etc? If you choose to measure based on the traditional Scope/Cost/Schedule metrics, some allowance should also be made for these things. Accepting all project change requests willy-nilly will inevitably cause problems, but so will refusing everything out of hand. Cultivating a rational process helps to strike a rational balance.</description>
            <link>http://www.projectconnections.com/templates/detail/requirements-change-management.html</link>
            <guid isPermaLink="false">A427FCB6-9948-4738-B53C-3669D3E92D36</guid>
            <pubDate>Tue, 13 May 2008 08:32:20 -0700</pubDate>
        </item>
    </channel>
</rss>
