<?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>Praktisk projektledning</title>
	<atom:link href="http://www.praktisk-projektledning.se/blog/?feed=rss2" rel="self" type="application/rss+xml" />
	<link>http://www.praktisk-projektledning.se/blog</link>
	<description>En projektledares funderingar</description>
	<lastBuildDate>Sun, 07 Feb 2010 10:47:24 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Kunskap från projekt till verksamhet</title>
		<link>http://www.praktisk-projektledning.se/blog/?p=22</link>
		<comments>http://www.praktisk-projektledning.se/blog/?p=22#comments</comments>
		<pubDate>Sun, 07 Feb 2010 10:47:24 +0000</pubDate>
		<dc:creator>Henrik R</dc:creator>
				<category><![CDATA[Okategoriserade]]></category>

		<guid isPermaLink="false">http://www.praktisk-projektledning.se/blog/?p=22</guid>
		<description><![CDATA[<p>En del verksamheter brottas med problemet att få tillgång till den kunskap som kommer fram i olika projekt. En del projekt brottas med problemet att verksamheten inte tar till sig den kunskap som kommer fram i projektet. En del av detta belyses i en avhandling som ComputerSweden skriver om i en artikel, &#8221;Därför kraschar ditt [...]]]></description>
			<content:encoded><![CDATA[<p>En del verksamheter brottas med problemet att få tillgång till den kunskap som kommer fram i olika projekt. En del projekt brottas med problemet att verksamheten inte tar till sig den kunskap som kommer fram i projektet. En del av detta belyses i en avhandling som ComputerSweden skriver om i en artikel, &#8221;<a href="http://computersweden.idg.se/2.2683/1.290520/darfor-kraschar-ditt-projekt" target="_blank">Därför kraschar ditt projekt</a>&#8221;. I artikeln skrivs det om svårigheter och konflikter kring hur kunskapsöverföringen ska ske när projekten är klara, samt att det gäller inte bara att medarbetarna har kunskaper &#8211; de måste också kunna använda dem.</p>
<p>De fem tips som redovisas i artikeln tycker jag är väl tekniska. Jag tycker att man glömmer det enkla, nämligen att se till att involvera verksamheten  i projektet. De som ska praktisera projektresultatet ska vara delaktiga genom hela projektet i avstämningsmöten, direkt projektarbete etc. Sedan gäller det också att få dem engagerade, då projektet trots allt blir en störning i deras normala arbetsuppgifter.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.praktisk-projektledning.se/blog/?feed=rss2&amp;p=22</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Ansvaret att förstå</title>
		<link>http://www.praktisk-projektledning.se/blog/?p=16</link>
		<comments>http://www.praktisk-projektledning.se/blog/?p=16#comments</comments>
		<pubDate>Fri, 09 Oct 2009 12:29:13 +0000</pubDate>
		<dc:creator>Henrik R</dc:creator>
				<category><![CDATA[Okategoriserade]]></category>
		<category><![CDATA[IT-projekt]]></category>
		<category><![CDATA[Kravspecifikation]]></category>
		<category><![CDATA[Ledarskap]]></category>
		<category><![CDATA[Scope]]></category>

		<guid isPermaLink="false">http://www.praktisk-projektledning.se/blog/?p=16</guid>
		<description><![CDATA[<p>Nättidningen foretagande.se har en artikel kallad &#8221;Stora problem med IT-projekt&#8221;. Frånsett att jag är lite allergisk mot svepande formuleringar som utan källhänvisning refererar till &#8221;sanningar&#8221; (såsom &#8221;25 procent av alla större it-utvecklingsprojekt havererar&#8221; etc) så pekar författaren, Magnus Brorsson, på en del intressanta punkter.</p>
<p>1. Gör en ordentlig kravspecifikation. Ja, det menar jag är nödvändigt i alla projekt.</p>
<p>2. [...]]]></description>
			<content:encoded><![CDATA[<p>Nättidningen <a href="http://www.foretagande.se/" target="_blank">foretagande.se </a>har en artikel kallad &#8221;<a href="http://www.foretagande.se/E-handel/Stora-problem-med-IT-projekt.html" target="_blank">Stora problem med IT-projekt</a>&#8221;. Frånsett att jag är lite allergisk mot svepande formuleringar som utan källhänvisning refererar till &#8221;sanningar&#8221; (såsom &#8221;25 procent av alla större it-utvecklingsprojekt havererar&#8221; etc) så pekar författaren, Magnus Brorsson, på en del intressanta punkter.</p>
<p>1. Gör en ordentlig kravspecifikation. Ja, det menar jag är nödvändigt i alla projekt.</p>
<p>2. Gärna funktionskrav i stället för tekniska krav. Ja, jag skulle även vilja stärka det genom att byta ut &#8221;Gärna&#8221; mot &#8221;Alltid&#8221;. Så gott som alltid bör beställaren av ett projekt, ovasett projekttyp, koncentrera sig på <em>vad</em> som ska uppnås, inte <em>hur</em> det ska uppnås.</p>
<p>3. Författaren anser att det är viktigt med ett ordentligt avtal som är kryddat med både morot och käpp. Föga underligt kanske med tanke på att författaren är jurist och jobbar med avtalsskrivande. Dock är min erfarenhet att under projektets gång så har varken morötter eller piskor inte speciellt mycket att tillföra för att få ett lyckat projektresultat.</p>
<p>4. I artikeln hävdas också att man bör skriva in &#8221;flexibla system för att hantera förändringar i projektet&#8221;. Lite oklart vad författaren menar just här, men i alla projekt är det nödvändigt att göra klart från början hur change-hanteringen ska gå till. Dvs hur man ska hantera en situation där olika parter vill ha ändringar i scope, funktion etc.</p>
<p>5. Artikeln påpekar också om vikten av &#8221;otvetydiga regler om testning, godkännande och leveranstider&#8221;. Håller helt med, och detta är applicerbart på alla projekt. Det vill säga att definiera innan projektet vad som ska anses som ett leveransgodkännande.</p>
<p>Min åsikt är att som projektledare bör du innan projektet startar bl a se till att kraven är tydliga, att scopet är väldefinierat, att changehanteringen är överenskommen, att regelverket för leveransgodkännande är tydligt. Och som projektledare räcker det inte att just du tycker att allt detta är tydligt och klart &#8211; det gäller också att se till att beställaren tycker det och att ni menar samma sak. Där kommer projektledarens förmåga till kommunikation in. Ansvaret att se till att projektets alla intressenter förstår projektets omfattning, mål och syfte ligger hos projektledaren. Om inte annat som ren självbevarelsedrift.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.praktisk-projektledning.se/blog/?feed=rss2&amp;p=16</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Intro till bloggen</title>
		<link>http://www.praktisk-projektledning.se/blog/?p=9</link>
		<comments>http://www.praktisk-projektledning.se/blog/?p=9#comments</comments>
		<pubDate>Thu, 24 Sep 2009 17:46:59 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Bloggen]]></category>
		<category><![CDATA[Sajten]]></category>

		<guid isPermaLink="false">http://www.praktisk-projektledning.se/blog/?p=9</guid>
		<description><![CDATA[Presentation av [...]]]></description>
			<content:encoded><![CDATA[<p>På bloggen Praktisk projektledning kommer det att publiceras en projektledares tankar om projektledning, ledarskap och kanske livet överhuvudtaget.</p>
<p>Känn er välkomna att i <a href="http://www.praktisk-projektledning.se/blog/?page_id=5" target="_self">Gästboken</a> dela med er av tankar och idéer liksom att skapa debatter!</p>
<p>På sajten <a href="http://www.praktisk-projektledning.se/" target="_blank">Praktisk Projektledning</a> finns en del tips och råd i mer konkret format, titta gärna in där!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.praktisk-projektledning.se/blog/?feed=rss2&amp;p=9</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
