<?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>Not For Slaves &#187; Project Management</title>
	<atom:link href="http://blog.daisho-blacksmith.com/category/project-management/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.daisho-blacksmith.com</link>
	<description></description>
	<lastBuildDate>Sun, 06 Jun 2010 21:44:38 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Two things to know about project management: “Managing risks and expectations”.</title>
		<link>http://blog.daisho-blacksmith.com/2007/08/two-things-to-know-about-project-management-%e2%80%9cmanaging-risks-and-expectations%e2%80%9d/</link>
		<comments>http://blog.daisho-blacksmith.com/2007/08/two-things-to-know-about-project-management-%e2%80%9cmanaging-risks-and-expectations%e2%80%9d/#comments</comments>
		<pubDate>Tue, 07 Aug 2007 10:22:35 +0000</pubDate>
		<dc:creator>Klaus Wiedemann</dc:creator>
				<category><![CDATA[Project Management]]></category>

		<guid isPermaLink="false">http://not-for-slaves.de/index.php/two-things-to-know-about-project-management-%e2%80%9cmanaging-risks-and-expectations%e2%80%9d/</guid>
		<description><![CDATA[In our recent series on project management, we covered a couple of aspects to consider when running a project.
In case you just don&#8217;t have the time to read through all of this, I would like to share a short cut with you. It is an advice I got from an experienced manager at Andersen Consulting [...]]]></description>
			<content:encoded><![CDATA[<p>In our recent series on project management, we covered a couple of aspects to consider when running a project.</p>
<p>In case you just don&#8217;t have the time to read through all of this, I would like to share a short cut with you. It is an advice I got from an experienced manager at Andersen Consulting when I was joining the firm in the early 90ies. And I found it invaluable since:</p>
<blockquote><p>Project management is all about managing risks and expectations.</p></blockquote>
<p>That&#8217;s it. Nothing more. This might sound surprisingly trivial. In fact, it&#8217;s not.</p>
<p>A project usually gets in trouble if it can not meet the expectations associated with it. Expectations about the timeline, budget or the final results. Expectations about required contributions from project members or outside ressources. Expectations about risks, difficulties or dependencies. About political support. Or the qualifications of team members.</p>
<p>Why is it important to actively manage expectations? Just think about the weather forecast: The forecast is for a mild spring day, sunny and warm. What do you get instead? &#8211; A snowstorm. And you did not bring a coat nor an umbrella. Of course, you are mad. If they would have announced the snowstorm, you would probably not like it either, but you could have prepared for it.</p>
<p>Now compare that with running a project. Nobody likes a project running late. But everybody hates the surprise to learn about it in the very last moment. What is a project causing running late or out of budget? Risks.</p>
<p>Risks are the other side of the equation.  If you are aware of risks, you can plan for. And, even more important, you can communicate them early. In fact, you <em>have </em>to communicate them. &#8220;It is not unusual during this time of the year, that a snowstorm is coming out of the blue, so better bring an umbrella even if it looks sunny.&#8221;</p>
<p>Once you communicate risks, chances are that you get either support in avoiding the risks, or you can mitigate the potential impact of such a risk.</p>
<p>So, whenever you are about to start a project, even if you forgot everything else you ever heard about project management. Always remember this: Manage risks and expectations.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.daisho-blacksmith.com/2007/08/two-things-to-know-about-project-management-%e2%80%9cmanaging-risks-and-expectations%e2%80%9d/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>Project Set Up as Critical Success Factor</title>
		<link>http://blog.daisho-blacksmith.com/2007/08/project-set-up-as-critical-success-factor/</link>
		<comments>http://blog.daisho-blacksmith.com/2007/08/project-set-up-as-critical-success-factor/#comments</comments>
		<pubDate>Fri, 03 Aug 2007 09:02:43 +0000</pubDate>
		<dc:creator>Carmen Schubert</dc:creator>
				<category><![CDATA[Project Management]]></category>

		<guid isPermaLink="false">http://not-for-slaves.de/index.php/project-set-up-as-critical-success-factor/</guid>
		<description><![CDATA[While numerous articles and books have been published on how to run projects successfully, most of them focus on formal aspects of project management: How to make gant charts, manage the critical path and how to do proper project controlling. In our experience, it is important to know the theory, but during the practical application, [...]]]></description>
			<content:encoded><![CDATA[<p>While numerous articles and books have been published on how to run projects successfully, most of them focus on formal aspects of project management: How to make gant charts, manage the critical path and how to do proper project controlling. In our experience, it is important to know the theory, but during the practical application, we experienced project management theory to contribute only a smaller part to the success of a project. In <a href="http://not-for-slaves.de/index.php/successfully-building-project-teams/" target="_blank">our series</a>, we try to shed some light on some of the more informal aspects of successfully running a project. Usually, it is said that running a project requires good coordination. Well, yeah!</p>
<p>However, there is no single best way to coordinate a project</p>
<p><strong>Project Set Up</strong></p>
<p>Project success is highly dependent on the project characteristics and initial set-up. The size and form of the project hereby plays an important role. It is a major difference if it is a new, innovative project or a “standard project” that has been done before, or if it is made up of 5 or 30 team members (actually, we do not cover here very large projects, but rather the majority of the projects. The larger a project gets, the more important formal project management gets).</p>
<p>Running a project where team members know each other saves time and effort of building relationships. Due to the fact that they have already worked together, the team works more efficiently. If the members of the project team have not worked together before, time has to be invested (and planned for!) to get to know each other and to form a team.</p>
<p>Whether team members work full-time or part-time in a project also effects (or restricts) coordination and as a consequence, the results of the project. It is much more difficult to organize meetings and coordinate activities if a team member only works three days a week on the project. The physical distance to other team members also has impacts on communication and coordination. If the team works together in one office, information, problems, findings and results can be shared more easily and quickly. Whereas if the team is separated (either through separated offices or locations), it takes longer to communicate with each other and therefore, also requires higher efforts to coordinate.<span id="more-42"></span></p>
<p>Therefore, before even try to establish coordination procedures in a project, it is worthwhile first to try to optimize the initial settings to minimize potential hazzle:</p>
<ul>
<li>Try to get full-time project members.</li>
</ul>
<ul>
<li>Try to get a team which has worked together before. I consider it preferable to have team members with known strengths and weaknesses. This reduces the unknown risk factors: You can plan with known weak team members, but it is much more difficult to keep a project on track where you find out about weak team members in the middle of the project.</li>
</ul>
<ul>
<li>Try to get your team at one location, on one floor level, or, if possible, within one room. Fight for that! This reduces the effort to communicate relevant information, and reduces time to handle information gaps and misunderstandings. Even with all modern communication tools, nothing beats personal face to face communication with no set-up effort.</li>
</ul>
<p>Only after you tried everything to optimize the project set-up for internal communication (and there will be always real-world restrictions in your way), you should think about communication and coordination channels, such as</p>
<ul>
<li>Formal team meetings,</li>
</ul>
<ul>
<li>Status reports,</li>
</ul>
<ul>
<li>Email distribution lists,</li>
</ul>
<ul>
<li>Video conferences,</li>
</ul>
<ul>
<li>Steering committees meeting,</li>
</ul>
<ul>
<li>Wikis</li>
</ul>
<ul>
<li>and all the other ways people invent to work around a sub-optimal project set-up.</li>
</ul>
<p>Upcoming next: The two things to know about project management: <strong>“Managing risks and expectations”</strong>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.daisho-blacksmith.com/2007/08/project-set-up-as-critical-success-factor/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Successfully Building Project Teams</title>
		<link>http://blog.daisho-blacksmith.com/2007/07/successfully-building-project-teams/</link>
		<comments>http://blog.daisho-blacksmith.com/2007/07/successfully-building-project-teams/#comments</comments>
		<pubDate>Tue, 10 Jul 2007 15:44:20 +0000</pubDate>
		<dc:creator>Carmen Schubert</dc:creator>
				<category><![CDATA[Project Management]]></category>

		<guid isPermaLink="false">http://not-for-slaves.de/?p=25</guid>
		<description><![CDATA[Running a project at the same time while working on other tasks can be quite a challenge. In order to manage both effectively, Hal Macomber provides on his blog ten rules that might help to improve project work.
Referencing all rules would take too much time &#8211; and you have probably other things to do. I [...]]]></description>
			<content:encoded><![CDATA[<p>Running a project at the same time while working on other tasks can be quite a challenge. In order to manage both effectively, Hal Macomber provides on <a target="_blank" href="http://www.reformingprojectmanagement.com/lenses/project-leadership/ten-new-rules-for-project-managers/">his blog</a> ten rules that might help to improve project work.</p>
<p>Referencing all rules would take too much time &#8211; and you have probably other things to do. I rather decided to select three rules that from my point of view are worth talking about and focus on them one by one.</p>
<p>The first to start with is <strong>“Build relationships intentionally”</strong></p>
<p>Building relationships with the team members of the project are essential and should therefore be the first step before starting the project. To work together efficiently in the project, people need to get to know each other and create trust. By respecting and helping each other, team spirit can be created. This is important for the success of the project.<span id="more-25"></span></p>
<p>Honestly, it is easier to write and talk about it than to put it into practice. It is often challenging to build solid working relationships, if people do not know each other, and if they do not work full-time on the project.</p>
<p>According to my experience, people who do not dedicate a significant amount of their time to a project just tend to create overhead. Especially if they need to coordinate and arrange a lot with other team members who work full-time for the project. In such a case, you should at least consider whether you can afford to “kick” these part-time team members out of the project. Normally, it is better to have fewer people on a project, with most of them available full-time.</p>
<p>Just some aspects that worked for me when building project teams:</p>
<ul>
<li>If the project is rather a major undertaking, try to organize a kick-off event with some adrenalin involved. Special events, like canyoning, rafting or similar activities work great (… just make sure that your team members have the physical condition to participate). If you hang on a rope while climbing down a cliff with your team members holding the rope, the relationship to your team members can not become any stronger…</li>
</ul>
<ul>
<li>Establish a small set of “project rules” right from the beginning, so that each team member knows what is expected of her and what is important.</li>
</ul>
<ul>
<li>Assign clear responsibilities &#8211; it is also essential that each member knows what he is responsible for.</li>
</ul>
<ul>
<li>Make sure that everybody subscribes to the goals of the projects. But be sensitive to the personalities of your team members: while some people just get excited by BHAGs (big hairy audacious goals), others just stall and panic.</li>
</ul>
<p>Jon R. Katzenbach mentions in his excellent book “Wisdom of Teams” that high pressure coming from the outside can be a success factor for high-performing teams, too. From my point of view, he is definitely right about that. It is incredible what you can achieve with a team that is facing a “nobody believes we can do this” attitude. This is really a rewarding experience if you finally made it. But, of course, you do not want to have these situations too often.</p>
<p>In my opinion, the opposite is also true: if goals are too easy to achieve and nobody feels committed to them, you will not even achieve trivial goals.</p>
<p>Coming up soon, the rule that leads to successful project work: <strong>“Coordination and collaboration”</strong>.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.daisho-blacksmith.com/2007/07/successfully-building-project-teams/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Good Project Management &#8211; just luck?</title>
		<link>http://blog.daisho-blacksmith.com/2007/06/good-project-management-just-luck/</link>
		<comments>http://blog.daisho-blacksmith.com/2007/06/good-project-management-just-luck/#comments</comments>
		<pubDate>Thu, 28 Jun 2007 17:15:14 +0000</pubDate>
		<dc:creator>Carmen Schubert</dc:creator>
				<category><![CDATA[Project Management]]></category>

		<guid isPermaLink="false">http://not-for-slaves.de/?p=18</guid>
		<description><![CDATA[Wayne Turk from the IT Manager&#8217;s Journal raises in his article the question whether good project management is an art, science or just dumb luck. This is a good question. He argues that it would be actually a little bit of all three. Project Management requires flexibility and creativity &#8211; this can be counted as [...]]]></description>
			<content:encoded><![CDATA[<p>Wayne Turk from the <a href="http://www.itmanagersjournal.com/feature/22281" target="_blank">IT Manager&#8217;s Journal</a> raises in his article the question whether good project management is an art, science or just dumb luck. This is a good question. He argues that it would be actually a little bit of all three. Project Management requires flexibility and creativity &#8211; this can be counted as art-, but there are also some rules to follow which belong to science.  Luck helps, but is not required in my opinion. Wayne Turk is listing 15 key principles for good project management, and all of them are very valid (although some are very IT specific). It is no guarantee for success, but by following these principles you might come a bit closer to it.</p>
<p>Referencing all principles would take too much time &#8211; and you have probably other things to do &#8211; so let me just focus on two or three of them that from my point of view are worth talking about in more detail.</p>
<p><strong>-  &#8220;<em>Three primary objectives &#8211; cost, schedule and quality &#8211; must be top concerns.</em>&#8221; </strong><br />
Project success is measured by the completion of the project with having the results on time, within the budget and on a high-quality level. It is not always possible to put this objective into practice but you should try, otherwise the project will fail.<br />
<strong><br />
-  &#8220;<em>Set priorities; then re-examine them periodically.</em>&#8221; </strong><br />
Setting priorities is essential in project management, especially if you have several projects running at the same time. Place the project with the highest priority first and then the ones  with the least priority.</p>
<p><strong>-  &#8220;<em>Good people with the right tools can make or break a project.</em>&#8220;</strong><br />
Having the right tool will definitely contribute to the success of a project, but having good people is more important (And excellent people usually start to make their own tools, if they do not have the right ones&#8230;). A proper management software combined with the right methodology brings you already a long way.</p>
<p>If you do not have the time to read through Wayne&#8217;s article, here is my one-line project management guideline:</p>
<p align="center"><strong>&#8220;Project Management: Managing Risks and Expectations&#8221;</strong></p>
<p align="left">All other details basically follow automatically once you take these two aspects very serious. E.g. cost, time, quality: what does the customer expect, what are the risks associated with it? How can you ensure that the actual expectations are in line with the project progress?</p>
<p align="left">These are topics of two upcoming articles on &#8220;Risk Management&#8221; and &#8220;Expectations Management&#8221;.</p>
<p align="left">&nbsp;</p>
<p align="left">&nbsp;</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.daisho-blacksmith.com/2007/06/good-project-management-just-luck/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
