<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>ProjectConnections Columns</title>
        <description>Ten most recent columns published on ProjectConnections.com</description>
        <link>http://www.projectconnections.com/articles/index.html</link>
        <copyright>2000</copyright>
        <docs>http://blogs.law.harvard.edu/tech/rss</docs>
        <language>en-us</language>
        <lastBuildDate>Wed, 30 Apr 2008 08:34:11 -0700</lastBuildDate>
        <managingEditor>deanna@projectconnections.com</managingEditor>
        <pubDate>Tue, 15 Apr 2008 15:07:51 -0700</pubDate>
        <webMaster>erik@projectconnections.com</webMaster>
        <generator>FeedForAll v2.0 (2.0.2.5) http://www.feedforall.com</generator>
        <item>
            <title>Customer Focus - The Essence of Agility: What makes a project &quot;Agile&quot;? Part 2 by Alan Koch</title>
            <description>It is all about our customer. All! An Agile team will do everything in their power to maintain continuous (or at least regular) contact with their customer, because that contact is essential to their ability to produce what the customer needs. An Agile team doesn&apos;t trust a Requirements Specification to tell the whole story. They know that if such a document was written, it contains errors, interpretations, and key omissions. They also know that even if it accurately represents what the customer thought they needed when they signed off, things are likely to change before the product is complete.
&lt;br /&gt;&lt;br /&gt;
In order to ensure that they deliver what the customer really needs (and needs today), the team includes the customer in team activities as often as possible. The customer&apos;s input is important in each phase of the Agile lifecycle.</description>
            <link>http://blog.projectconnections.com/alan_koch/2008/04/customer-focus.html</link>
            <guid isPermaLink="false">6E6ABA76-FB04-4EF3-8537-5B32C24A0DE9</guid>
            <pubDate>Wed, 30 Apr 2008 08:31:40 -0700</pubDate>
        </item>
        <item>
            <title>Great Careers for Great PMs by Cinda Voegtli</title>
            <description>In my previous posts, I&apos;ve provided my ideas about what constitutes a great PM. This time, I would like to bridge to what these ideas can mean for someone’s overall career. Of course, it seems obvious that if you’re a great PM, you&apos;ll get more opportunities. Certainly you’d seem like the person to call for bigger and hairier and more complex projects. But I bring this up because of the unexpected career paths I&apos;ve seen people take based on a foundation of PM ability. [Each of these people] had a really interesting mix of career experience-a series of positions that was not planned out for any of them, but evolved based on their performance, abilities, etc. From what I know of each of them, their opportunities came about because of their PM Greatness in particular areas that fit their environments and led to excellent performance of the job at hand, and the opportunity for the next great challenge.</description>
            <link>http://blog.projectconnections.com/executive_view/2008/04/in-my-previous.html</link>
            <guid isPermaLink="false">1CFA6DB5-15FE-4E16-B6D8-FE1F8BD91EA1</guid>
            <pubDate>Tue, 15 Apr 2008 10:38:54 -0700</pubDate>
        </item>
        <item>
            <title>User Illusions by Kent McDonald</title>
            <description>Agile advocates like to brag that one of the advantages of agile methods is that they stress regular involvement of the &quot;customer&quot; throughout the life of the project. They generally expect this role to tell the developers what functionality to work on, and in what order, and provide timely feedback on functionality so that the developers can respond accordingly. These methods take things a step further and also stress the need for a &lt;b&gt;&lt;i&gt;single&lt;/i&gt;&lt;/b&gt; customer providing this information. Some people refer to the concept as the &quot;single wringable neck.&quot; This view on customers is rather shortsighted and ironic coming from a community so focused on collaboration.</description>
            <link>http://blog.projectconnections.com/kent_mcdonald/2008/04/user-illusions.html</link>
            <guid isPermaLink="false">BAF5D486-72C5-4666-ACFA-7BC6CD2CC287</guid>
            <pubDate>Tue, 15 Apr 2008 10:38:35 -0700</pubDate>
        </item>
        <item>
            <title>Pay Attention To Me! by Brian Irwin</title>
            <description>&quot;The project sponsor, the Vice-President of the business unit, remains unresponsive to my requests for information. I sometimes send two or three reminder email queries about the same thing. Is there anything I can do?&quot;</description>
            <link>http://blog.projectconnections.com/brian_irwin/2008/04/pay-attention-t.html</link>
            <guid isPermaLink="false">69BF01A3-6412-4789-8266-7DCB0E3718ED</guid>
            <pubDate>Tue, 15 Apr 2008 10:38:34 -0700</pubDate>
        </item>
        <item>
            <title>From Process to Discipline  by Geof Lory</title>
            <description>The primary purpose of any team is to get work done in the most effective manner and achieve outcomes that add value. Ultimately, the result of the work is the value proposition and the interaction is just the means. But, so much of project management is about how the work gets done within the constraints of the project, not which work has been selected for the project. That is why there is so much focus on process-the flow of work and information within the project. There is a belief that if we improve the process, better work will get done faster and use less resources, which is the Holy Grail of Project Management.</description>
            <link>http://blog.projectconnections.com/geof_lory/2008/04/from-process-to.html</link>
            <guid isPermaLink="false">05259CD8-7C5E-46A6-9726-AC251B613140</guid>
            <pubDate>Wed, 2 Apr 2008 11:51:40 -0700</pubDate>
        </item>
        <item>
            <title>Being a Great Project Leader with a Mortgage and Kids in College by Kimberly Wiefling</title>
            <description>One of the strong beliefs that I have about effective project leadership is that it cannot be done by someone who has a mortgage, kids in college, or a spouse who doesn&apos;t work. In my experience, a project leader must often operate in an environment where the very people who sign their paychecks are also the biggest obstacles to success. But some people have asked what can be done if they DO rely on their job for the little niceties of life, like food, shelter, electricity and running water. After deep reflection on the matter, I am forced to admit that tact and diplomacy, while somewhat time consuming, may still have a place in the project leader&apos;s toolkit.</description>
            <link>http://blog.projectconnections.com/kimberly_wiefling/2008/04/being-a-great-p.html</link>
            <guid isPermaLink="false">CC2B0F8D-F0FF-40EB-AAFB-FDDD5D345159</guid>
            <pubDate>Wed, 19 Mar 2008 10:03:24 -0700</pubDate>
        </item>
        <item>
            <title>Perfection Not Required, Flexibility and Fit a Must by Cinda Voegtli</title>
            <description>A friend of mine is an IT director at a major computer company. He has a phrase: &quot;I have no use for content-free project managers.&quot; He has a group of 300 developers and works with project managers both inside his group and outside. His pet peeve is project managers who come and say things like, &quot;The schedule says you&apos;re supposed to be 40% complete by now but you marked your task 35% complete. When are you going to be back on track?&quot; In his mind, that project manager is doing no one any constructive good, and they get a reputation as being a paper-pushing status person. Even if someone else in the company has set that poor project manager up in a status-reporting-only role, that PM has lost all credibility with this pretty influential IT director.
&lt;br /&gt;&lt;br /&gt;
Now, does all this mean you can&apos;t be a great project manager if you&apos;re not an engineer? NO, in my opinion. I think the key is not necessarily exactly what type or how much or even whether you&apos;ve personally done technical design of x, y, or z type systems, etc. It&apos;s whether you understand enough about the particular kind of development, or systems, or customer applications, or whatever, to understand the team&apos;s issues...</description>
            <link>http://blog.projectconnections.com/executive_view/2008/03/perfection-not.html</link>
            <guid isPermaLink="false">999EDF80-85E4-4C32-9367-F3255DB91AD6</guid>
            <pubDate>Wed, 5 Mar 2008 09:28:08 -0800</pubDate>
        </item>
        <item>
            <title>The Tao, the I Ching, and a Little Non-Western Project Management Attitude  by Carl Pritchard</title>
            <description>For those who have never done any homework in the &lt;i&gt;I Ching&lt;/i&gt; (which translates to the &lt;i&gt;Book of Changes&lt;/i&gt;), it&apos;s often referred to as a fortune-telling device. Nothing could be further from the truth. It&apos;s actually a tool used to assess one&apos;s own attitudes in a context that had not previously been considered. In project management, we are often called upon to take on the role of prognosticators, as well as the role of seers of our own environment. And we are asked to cope with change. What better place to start than with the ancient &lt;i&gt;Book of Changes&lt;/i&gt;?</description>
            <link>http://blog.projectconnections.com/carl_pritchard/2008/04/the-tao-the-i-c.html</link>
            <guid isPermaLink="false">27A54070-3BAD-420A-AF82-6533E8A5A65F</guid>
            <pubDate>Wed, 5 Mar 2008 09:28:01 -0800</pubDate>
        </item>
        <item>
            <title>The Essence of Agility: What makes a project &quot;Agile&quot;? -  (Part 1 of 3)   by Alan Koch</title>
            <description>The Agile approach is often panned as an excuse for lack of discipline. I&apos;ve been told that Agility means, &quot;We&apos;ll just wing it, and when we run out of money, we&apos;ll ask for more.&quot; This and other such statements show that many people don&apos;t understand what Agility is all about.&lt;br /&gt;&lt;br /&gt;The confusion is understandable because there is a plethora of practices that people claim as &quot;Agile.&quot; And unfortunately, some of them are indeed using the term &quot;Agile&quot; as an excuse for lack of discipline.</description>
            <link>http://blog.projectconnections.com/alan_koch/2008/04/what-makes-a-pr.html</link>
            <guid isPermaLink="false">6ACB4A41-9748-4524-A626-73E16173CF87</guid>
            <pubDate>Thu, 21 Feb 2008 08:56:13 -0800</pubDate>
        </item>
        <item>
            <title>A Fool With a Tool by Kent McDonald</title>
            <description>You can see it coming a mile away. A project team runs into a problem managing requirements, keeping track of their project schedule, tracing their tests back to their requirements, or some other activity crucial to the success of a project. They get together (good sign) to discuss what they should do to improve their situation and inevitably the suggestion comes up, &quot;if only we had a tool to do that...&quot; And so it begins.&lt;br /&gt;&lt;br /&gt;
Teams often look at tools as the silver bullet to slay all of their problems; and when used correctly, they can keep most werewolves at bay. Thing is, tools can also cause more problems than they solve, especially in the hands of those not completely prepared to use them.</description>
            <link>http://blog.projectconnections.com/kent_mcdonald/2008/04/a-fool-with-a-t.html</link>
            <guid isPermaLink="false">6A81226C-5FE7-4387-B4C0-6F2E7636D2D0</guid>
            <pubDate>Tue, 5 Feb 2008 10:23:02 -0800</pubDate>
        </item>
        <item>
            <title>Executive Views on Great PMs by Cinda Voegtli</title>
            <description>So what DO executives think of us as project managers and what do they value? I know from conferences and other interaction with project managers that being valued by their executives is something of a holy grail - and seemingly not nearly common enough. Thinking back, I realize that I was about 7 years into my career as an engineer and manager before I got even a first inkling from an exec of how they personally thought about project management. And I was 12 years in overall and about 6 years into project management work before I got really good role-modeling of true project leadership behavior - what upper-level courageous and business-focused PM role looks like - and direct messages from executives that  - this is what I’m looking for.  -  (Gad! How can we do these jobs for so long without better clues from the ultimate customer of our work?)</description>
            <link>http://blog.projectconnections.com/executive_view/2008/02/so-what-do-exec.html</link>
            <guid isPermaLink="false">7E66F42A-014D-4CDC-84CE-D2C65377300F</guid>
            <pubDate>Tue, 5 Feb 2008 10:23:01 -0800</pubDate>
        </item>
    </channel>
</rss>
