<?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/"
	>

<channel>
	<title>Project Management - Troubled Projects</title>
	<atom:link href="http://troubledprojectsmanagement.blog.com/feed/" rel="self" type="application/rss+xml" />
	<link>http://troubledprojectsmanagement.blog.com</link>
	<description></description>
	<pubDate>Mon, 04 May 2009 17:27:06 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Ideas to Avoid Issues while Managing Projects with State Owned Customers</title>
		<link>http://troubledprojectsmanagement.blog.com/2009/05/04/ideas-to-avoid-issues-while-managing-projects-with-state-owned-customers/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2009/05/04/ideas-to-avoid-issues-while-managing-projects-with-state-owned-customers/#comments</comments>
		<pubDate>Mon, 04 May 2009 17:27:06 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[Well, I was discussing about this topic with some of my colleagues<br />
and some ideas came up:<br />
<br />
1. After you receive the contract awarding letter you usually have a few days to review<br />
&#160;the contract and sign it, make sure to include the following clauses:<br />
<ul>
<li>A checklist that will be used by&#160;the customer to accept your deliverables, this can be negotiated but always is better to negotiate it now and not after the clock is ticking.</li>
<li>An escalation process to deal with issues.</li>
<li>A clear list of roles and responsibilities on the customer side, and always stating that if one of those responsibilities is missed a change on time, costs and/or quality will apply.</li>
</ul>
<p>**Remember: what is not written in the contract simply does not exist for them, you may have the best PM methodology, if it is not within the contract they will neglect everything you may propose or suggest to improve the project's performance...please be anoying with the sales and legal guys in your company&#160;to get these and other ideas&#160;written in the contract. **</p>
<p>2. While constructing your proposal, usually the RFP has a time constraint. Use the time between the awarding letter and contract sign off for planning, work hard on this short period of time to advance as much as you can on planning stuff. Don't wait to sign the contract to start...&#160;</p>
<p>JD</p>

]]></description>
			<content:encoded><![CDATA[<div>Well, I was discussing about this topic with some of my colleagues<br />
and some ideas came up:</p>
<p>1. After you receive the contract awarding letter you usually have a few days to review<br />
&#160;the contract and sign it, make sure to include the following clauses:</p>
<ul>
<li>A checklist that will be used by&#160;the customer to accept your deliverables, this can be negotiated but always is better to negotiate it now and not after the clock is ticking.</li>
<li>An escalation process to deal with issues.</li>
<li>A clear list of roles and responsibilities on the customer side, and always stating that if one of those responsibilities is missed a change on time, costs and/or quality will apply.</li>
</ul>
<p>**Remember: what is not written in the contract simply does not exist for them, you may have the best PM methodology, if it is not within the contract they will neglect everything you may propose or suggest to improve the project&#8217;s performance&#8230;please be anoying with the sales and legal guys in your company&#160;to get these and other ideas&#160;written in the contract. **</p>
<p>2. While constructing your proposal, usually the RFP has a time constraint. Use the time between the awarding letter and contract sign off for planning, work hard on this short period of time to advance as much as you can on planning stuff. Don&#8217;t wait to sign the contract to start&#8230;&#160;</p>
<p>JD</p>
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2009/05/04/ideas-to-avoid-issues-while-managing-projects-with-state-owned-customers/feed/</wfw:commentRss>
		</item>
		<item>
		<title>What to do when a customer doesn&#8217;t care about PM methodology?</title>
		<link>http://troubledprojectsmanagement.blog.com/2009/01/30/what-to-do-when-a-customer-doesnt-care-about-pm-methodology/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2009/01/30/what-to-do-when-a-customer-doesnt-care-about-pm-methodology/#comments</comments>
		<pubDate>Thu, 29 Jan 2009 20:07:48 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[Mainly in state owned companies,&#160;when they are&#160;customers,&#160;is very common that<br />
the project sponsor&#160;or the person in charge of the contract doesn't care about your<br />
PM methodology.<br />
You may face a cruel reality, that person might say to you: " I don't care about<br />
documentation, I don't care about your schedule nor milestones. You have to<br />
deliver the project on X date or I will apply the financial penalty...".<br />
This reality is even worst when the customer is responsible for certain milestones<br />
that will&#160;destroy your&#160;schedule variance if the don't meet the deadlines. You, again,<br />
are between a rock and a hard place, because your find that they don't really care<br />
about the timelines but at the same time you have a contract that allows them to<br />
punish you if the final target date is not met.<br />
This kind of people of course will refuse to sign a document stating that the delay is their<br />
fault and that they&#160;will approve a target date change. Why? because, in a public company,<br />
this would lead to an internal investigation and if they are found guilty they will face severe<br />
consequences.<br />
What can we do on such a creepy scenario?<br />
I have some ideas that can be useful:<br />
<br />
1. Always work on building a good trust relationship with the person in charge of your contract.<br />
2. Don't pick a fight. Always try to negotiate...even when you feel that&#160;you are loosing..<br />
3.&#160;If things get out of control, you must scalate the problem and involve upper management<br />
&#160;&#160;&#160; in both sides to find a solution prior penalties. Please, do this while you still have some time.<br />
4. Even when some customers don't not allow this by law, try to include scalation processes<br />
&#160;&#160;&#160; in the contract clauses.<br />
<br />
If I find more ways to deal with this pain..I will post them....good luck!<br />
<br />
JD
]]></description>
			<content:encoded><![CDATA[<div>Mainly in state owned companies,&#160;when they are&#160;customers,&#160;is very common that<br />
the project sponsor&#160;or the person in charge of the contract doesn&#8217;t care about your<br />
PM methodology.<br />
You may face a cruel reality, that person might say to you: &#8221; I don&#8217;t care about<br />
documentation, I don&#8217;t care about your schedule nor milestones. You have to<br />
deliver the project on X date or I will apply the financial penalty&#8230;&#8221;.<br />
This reality is even worst when the customer is responsible for certain milestones<br />
that will&#160;destroy your&#160;schedule variance if the don&#8217;t meet the deadlines. You, again,<br />
are between a rock and a hard place, because your find that they don&#8217;t really care<br />
about the timelines but at the same time you have a contract that allows them to<br />
punish you if the final target date is not met.<br />
This kind of people of course will refuse to sign a document stating that the delay is their<br />
fault and that they&#160;will approve a target date change. Why? because, in a public company,<br />
this would lead to an internal investigation and if they are found guilty they will face severe<br />
consequences.<br />
What can we do on such a creepy scenario?<br />
I have some ideas that can be useful:</p>
<p>1. Always work on building a good trust relationship with the person in charge of your contract.<br />
2. Don&#8217;t pick a fight. Always try to negotiate&#8230;even when you feel that&#160;you are loosing..<br />
3.&#160;If things get out of control, you must scalate the problem and involve upper management<br />
&#160;&#160;&#160; in both sides to find a solution prior penalties. Please, do this while you still have some time.<br />
4. Even when some customers don&#8217;t not allow this by law, try to include scalation processes<br />
&#160;&#160;&#160; in the contract clauses.</p>
<p>If I find more ways to deal with this pain..I will post them&#8230;.good luck!</p>
<p>JD
</p></div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2009/01/30/what-to-do-when-a-customer-doesnt-care-about-pm-methodology/feed/</wfw:commentRss>
		</item>
		<item>
		<title>PMI vs Prince2..which one is the best methodology?</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/11/24/pmi-vs-prince2which-one-is-the-best-methodology/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/11/24/pmi-vs-prince2which-one-is-the-best-methodology/#comments</comments>
		<pubDate>Mon, 24 Nov 2008 13:50:40 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[Today a colleague asked me an interesting question,&#160;in order to include screening&#160;for PM methodologies&#160;on an&#160;RFP. Which one the best??? PMI's or Price2's??????<br />
<br />
<!--StartFragment -->In my experience, while having Prince2 and PMP certifications, PMI methodology is more known and preferred among the customers.<br />
<br />
The main reasons are:<br />
<br />
1. The PMI has way more market penetration outside Europe of their methodology than the APMG. This is because of a large number of&#160;education partners and consulting companies promoting the PMP certification.<br />
2. PMI Methodology, in my opinion, is easier to understand from a customer point of view. It has less administrative focus and their processes interactions are easier to detect while monitoring a project.<br />
<br />
However, a good screening suggestion on PM methodologies that I've used when helping our customers to build RFPs is asking to demonstrate certified professionals on recognized international methodologies like PMI and/or Prince2. As the main purpose of applying PM methodologies is to ensure the project's performance which can be done with both PM methodologies.<br />
<br />
JD<br />
&#160;
]]></description>
			<content:encoded><![CDATA[<div>Today a colleague asked me an interesting question,&#160;in order to include screening&#160;for PM methodologies&#160;on an&#160;RFP. Which one the best??? PMI&#8217;s or Price2&#8217;s??????</p>
<p><!--StartFragment -->In my experience, while having Prince2 and PMP certifications, PMI methodology is more known and preferred among the customers.</p>
<p>The main reasons are:</p>
<p>1. The PMI has way more market penetration outside Europe of their methodology than the APMG. This is because of a large number of&#160;education partners and consulting companies promoting the PMP certification.<br />
2. PMI Methodology, in my opinion, is easier to understand from a customer point of view. It has less administrative focus and their processes interactions are easier to detect while monitoring a project.</p>
<p>However, a good screening suggestion on PM methodologies that I&#8217;ve used when helping our customers to build RFPs is asking to demonstrate certified professionals on recognized international methodologies like PMI and/or Prince2. As the main purpose of applying PM methodologies is to ensure the project&#8217;s performance which can be done with both PM methodologies.</p>
<p>JD<br />
&#160;
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/11/24/pmi-vs-prince2which-one-is-the-best-methodology/feed/</wfw:commentRss>
		</item>
		<item>
		<title>TROUBLES CLOSING A PROJECT</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/10/10/troubles-closing-a-project/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/10/10/troubles-closing-a-project/#comments</comments>
		<pubDate>Fri, 10 Oct 2008 18:14:02 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[It's very important to take good care&#160;of the PM methodology, no matter the size of<br />
your project.<br />
Even&#160;for small&#160;projects if you forget something at the initiation stage you will regret<br />
at the closing stage. A good example happened to me, one of the most experienced<br />
PMs was managing a routinary small project and, as a service company, we must&#160;<br />
meet certain requirements&#160;to recognize the revenue coming from projects, we committed<br />
to finish the project and have all the requirements done before the last day of the month<br />
to recognize the revenue. That day I had a small meeting with the PM to check if everything<br />
was OK with the project and we had all the documentation to close the project and formally<br />
recognize the revenue, the answer was: "The project is done, everything is working OK but I<br />
really don't have clear what we need to close the project and recognize the revenue". WHY?<br />
The PM never asked to the Sales person the Purchase Order or the contract that we had to<br />
make that project, so he didn't know how the customer would legally signoff the project and<br />
we would be able to recognize our revenue. This surprise&#160;in the last day to close the project<br />
was very scary as we needed the money to be profitable that month. Fortunately we could<br />
complete the signoff process on the very last minute and the money was in our pocket.<br />
The lesson learnt&#160;is something that we can not afford to forget: *Always* Get the commercial<br />
proposal and the contract (or Purchase Order)&#160;as part of your Statement of Work at the<br />
initiation stage read them well and&#160;keep them handy during the whole project...no matter the size<br />
...no matter that you have done that job so many times before.<br />
JD
]]></description>
			<content:encoded><![CDATA[<div>It&#8217;s very important to take good care&#160;of the PM methodology, no matter the size of<br />
your project.<br />
Even&#160;for small&#160;projects if you forget something at the initiation stage you will regret<br />
at the closing stage. A good example happened to me, one of the most experienced<br />
PMs was managing a routinary small project and, as a service company, we must&#160;<br />
meet certain requirements&#160;to recognize the revenue coming from projects, we committed<br />
to finish the project and have all the requirements done before the last day of the month<br />
to recognize the revenue. That day I had a small meeting with the PM to check if everything<br />
was OK with the project and we had all the documentation to close the project and formally<br />
recognize the revenue, the answer was: &#8220;The project is done, everything is working OK but I<br />
really don&#8217;t have clear what we need to close the project and recognize the revenue&#8221;. WHY?<br />
The PM never asked to the Sales person the Purchase Order or the contract that we had to<br />
make that project, so he didn&#8217;t know how the customer would legally signoff the project and<br />
we would be able to recognize our revenue. This surprise&#160;in the last day to close the project<br />
was very scary as we needed the money to be profitable that month. Fortunately we could<br />
complete the signoff process on the very last minute and the money was in our pocket.<br />
The lesson learnt&#160;is something that we can not afford to forget: *Always* Get the commercial<br />
proposal and the contract (or Purchase Order)&#160;as part of your Statement of Work at the<br />
initiation stage read them well and&#160;keep them handy during the whole project&#8230;no matter the size<br />
&#8230;no matter that you have done that job so many times before.<br />
JD
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/10/10/troubles-closing-a-project/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Early Diagnosis - Easy Solution&#8230; Late Diagnosis - Painful Solution</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/09/02/early-diagnosis-easy-solution-late-diagnosis-painful-solution/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/09/02/early-diagnosis-easy-solution-late-diagnosis-painful-solution/#comments</comments>
		<pubDate>Tue, 02 Sep 2008 16:43:44 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[As Project Managers we should be identifying risks during the whole project life cycle,<br />
in order to prevent a troubled project and even more when we are already experiencing<br />
issues we must always encourage our team to&#160;see not only the project surface but to the<br />
&#160;details and to&#160;identify all the possible risks ...and of course perform good&#160;risks<br />
prioritization and&#160;good mitigation / prevention&#160;plans.<br />
<br />
Risks Identification:<br />
<br />
The best way to encourage risks identification is facilitating brainstorming sessions, usually<br />
&#160;at the&#160;begining of the project, a brainstorm session is valuable when&#160;conducted accordingly. On&#160;brainstorming, the #1 ground rule is&#160;DO NOT CRITICIZE, everyone&#160;must feel free<br />
enough to say whatever&#160;she/he is thinking.&#160;A very well mixed&#160;audience is also important,&#160;<br />
participants from several&#160;areas like engineering, finance, sales, taxes, HR, etc&#160;will be<br />
very helpful to identify risks that probably are not&#160;easy to find at the first sight.<br />
<br />
Again, a HARC - Hazard Identification and Risk Control&#160;- procedure will help a lot,<br />
specially if your project is being done in industrial environments.<br />
<br />
A good way to facilitate risks identification during the whole project life cycle is to<br />
implement a system for on-line risks identification and documentation,&#160;several tools<br />
exist for this purpose and will help you a lot to keep your risk register, action plans<br />
&#160;and follow up activities under control.<br />
<br />
Risk&#160;Response Plans:<br />
<br />
The mitigation / prevention plans must be very well defined and documented, setting<br />
a responsible person for each plan is key to have all the possible problems under control.<br />
<br />
Perform&#160;"What if" sessions with&#160;your team will help you&#160;to refine your response plans&#160;<br />
to be ready when something undesirable occurs.<br />
<br />
Remember, try to identify what is not OK soon in your project...don't wait to act...<br />
if you see something strange or dangerous you MUST do something NOW!<br />
<br />
JD<br />
&#160;
]]></description>
			<content:encoded><![CDATA[<div>As Project Managers we should be identifying risks during the whole project life cycle,<br />
in order to prevent a troubled project and even more when we are already experiencing<br />
issues we must always encourage our team to&#160;see not only the project surface but to the<br />
&#160;details and to&#160;identify all the possible risks &#8230;and of course perform good&#160;risks<br />
prioritization and&#160;good mitigation / prevention&#160;plans.</p>
<p>Risks Identification:</p>
<p>The best way to encourage risks identification is facilitating brainstorming sessions, usually<br />
&#160;at the&#160;begining of the project, a brainstorm session is valuable when&#160;conducted accordingly. On&#160;brainstorming, the #1 ground rule is&#160;DO NOT CRITICIZE, everyone&#160;must feel free<br />
enough to say whatever&#160;she/he is thinking.&#160;A very well mixed&#160;audience is also important,&#160;<br />
participants from several&#160;areas like engineering, finance, sales, taxes, HR, etc&#160;will be<br />
very helpful to identify risks that probably are not&#160;easy to find at the first sight.</p>
<p>Again, a HARC - Hazard Identification and Risk Control&#160;- procedure will help a lot,<br />
specially if your project is being done in industrial environments.</p>
<p>A good way to facilitate risks identification during the whole project life cycle is to<br />
implement a system for on-line risks identification and documentation,&#160;several tools<br />
exist for this purpose and will help you a lot to keep your risk register, action plans<br />
&#160;and follow up activities under control.</p>
<p>Risk&#160;Response Plans:</p>
<p>The mitigation / prevention plans must be very well defined and documented, setting<br />
a responsible person for each plan is key to have all the possible problems under control.</p>
<p>Perform&#160;&#8221;What if&#8221; sessions with&#160;your team will help you&#160;to refine your response plans&#160;<br />
to be ready when something undesirable occurs.</p>
<p>Remember, try to identify what is not OK soon in your project&#8230;don&#8217;t wait to act&#8230;<br />
if you see something strange or dangerous you MUST do something NOW!</p>
<p>JD<br />
&#160;
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/09/02/early-diagnosis-easy-solution-late-diagnosis-painful-solution/feed/</wfw:commentRss>
		</item>
		<item>
		<title>TROUBLED PROJECTS AND DIFFICULT CUSTOMERS</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/08/30/troubled-projects-and-difficult-customers/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/08/30/troubled-projects-and-difficult-customers/#comments</comments>
		<pubDate>Fri, 29 Aug 2008 22:30:41 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[<p>During a recent conference at my company I had this interesting question:<br />
<br />
What can I do when my project is in trouble, my customer is a state owned entity and my<br />
&#160;customer's sponsor&#160;doesn't&#160;cooperate at all to put the project back in track?<br />
<br />
Well, first of all, government or state owned entities are very difficult customers. Usually<br />
their projects are the result of a non very well&#160;structured&#160;feasiblity process and during<br />
the public bidding process your company accepts their rules, even your company has<br />
to agree to the customer's contract terms and conditions.<br />
<br />
Second, the person that is in charge of the project&#160;from the customer's side is more a<br />
contract "watching man" than a real project's sponsor. This person, in most of the cases,<br />
will be taking a close look to the contract's terms and conditions and will compare them<br />
against your actions. If you don't meet any of the contractc's T&#38;Cs you may expect a<br />
penalty warning rather than a good idea to help the project.<br />
<br />
With this landscape, if your project is in trouble you have to be very clever to manage<br />
this situation.<br />
<br />
In my experience, you will need to take good care of:<br />
<br />
1. Document, document and document: You need to focus on making all communications<br />
official. Always keep records of meeting minutes with all the attendees signatures, keep your<br />
&#160;issues log updated and distributed accordingly, ensure that you have documented records<br />
for all the deliverables already accepted.<br />
<br />
2. Focus on change management: Don't accept changes, in good faith,&#160;trying to buy customer's<br />
&#160;mercy. This will only add costs and&#160;more risks to your project and if your troubles continue<br />
your customer won't help you anyway... they&#160;have a contract to watch...they are&#160;public<br />
employees that can even go to jail if don't follow the rules...<br />
<br />
3. Memorize your project's contract: When in trouble, you need to be well prepared to face<br />
customer's requirements and demands. In a contract you have rights too!!<br />
<br />
4. Keep a project HARC up to date: A HARC...Hazard Analysis and Risk Control is a<br />
powerful tool when in trouble and even more when your customer is a government company.<br />
This will help to keep you and your team focused on the top priority issues to solve.<br />
<br />
And finally, follow your Project Management processes. For sure you will see how this will<br />
reward your efforts.<br />
<br />
JD<br />
<br />
<br />
<br /></p>

]]></description>
			<content:encoded><![CDATA[<div>
<p>During a recent conference at my company I had this interesting question:</p>
<p>What can I do when my project is in trouble, my customer is a state owned entity and my<br />
&#160;customer&#8217;s sponsor&#160;doesn&#8217;t&#160;cooperate at all to put the project back in track?</p>
<p>Well, first of all, government or state owned entities are very difficult customers. Usually<br />
their projects are the result of a non very well&#160;structured&#160;feasiblity process and during<br />
the public bidding process your company accepts their rules, even your company has<br />
to agree to the customer&#8217;s contract terms and conditions.</p>
<p>Second, the person that is in charge of the project&#160;from the customer&#8217;s side is more a<br />
contract &#8220;watching man&#8221; than a real project&#8217;s sponsor. This person, in most of the cases,<br />
will be taking a close look to the contract&#8217;s terms and conditions and will compare them<br />
against your actions. If you don&#8217;t meet any of the contractc&#8217;s T&amp;Cs you may expect a<br />
penalty warning rather than a good idea to help the project.</p>
<p>With this landscape, if your project is in trouble you have to be very clever to manage<br />
this situation.</p>
<p>In my experience, you will need to take good care of:</p>
<p>1. Document, document and document: You need to focus on making all communications<br />
official. Always keep records of meeting minutes with all the attendees signatures, keep your<br />
&#160;issues log updated and distributed accordingly, ensure that you have documented records<br />
for all the deliverables already accepted.</p>
<p>2. Focus on change management: Don&#8217;t accept changes, in good faith,&#160;trying to buy customer&#8217;s<br />
&#160;mercy. This will only add costs and&#160;more risks to your project and if your troubles continue<br />
your customer won&#8217;t help you anyway&#8230; they&#160;have a contract to watch&#8230;they are&#160;public<br />
employees that can even go to jail if don&#8217;t follow the rules&#8230;</p>
<p>3. Memorize your project&#8217;s contract: When in trouble, you need to be well prepared to face<br />
customer&#8217;s requirements and demands. In a contract you have rights too!!</p>
<p>4. Keep a project HARC up to date: A HARC&#8230;Hazard Analysis and Risk Control is a<br />
powerful tool when in trouble and even more when your customer is a government company.<br />
This will help to keep you and your team focused on the top priority issues to solve.</p>
<p>And finally, follow your Project Management processes. For sure you will see how this will<br />
reward your efforts.</p>
<p>JD</p>
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/08/30/troubled-projects-and-difficult-customers/feed/</wfw:commentRss>
		</item>
		<item>
		<title>EFFECTIVE PMO SUPPORT FOR TROUBLED PROJECTS</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/08/21/effective-pmo-support-for-troubled-projects/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/08/21/effective-pmo-support-for-troubled-projects/#comments</comments>
		<pubDate>Wed, 20 Aug 2008 22:10:13 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[<p>In many cases, the PMO´s value is not easy to see. Many Project Managers&#160;say that<br />
the PMOs are only focused on surveillance; watching if the projects are on time and<br />
on budget but when troubles appear, they don´t receive effective support from their PMO.<br />
<br />
Gartner has been researching about PMO best practices, and I must say that best practices<br />
to support troubled projects have to be embraced for your PMO in order really make<br />
&#160;a difference adding value to the business and ensure overall success of their projects<br />
portfolio.<br />
<br />
The number one action that a PMO has to take is to prevent that their projects fall into<br />
the danger zone, the PMO has to be proactive by periodically check every project for<br />
early warning signs. This check has to be done&#160;with each Project Manager; not using<br />
fancy reporting systems nor e mails but with a simple phone call or a&#160;face to face meeting<br />
&#160;whenever it´s possible. For projects with larger teams at the customer site or involving<br />
tasks in industrial environments where QHSE standards are key to the project success,<br />
the PMO must perform field visits to personally check the project´s health.<br />
<br />
Coaching and mentoring the Project Managers will always add more value than acting<br />
as a detective researching why bad things happened&#160;to a project.<br />
<br />
But what kind of support a Project Manager needs from his PMO when his project is<br />
&#160;already in trouble?<br />
<br />
The PMBOK mentions that only when a project is doomed, a rebaseline should be<br />
performed.<br />
<br />
The PMO must have standard processes to perform this project rebaseline to analyze,<br />
decide and&#160;execute the best alternative between:<br />
<br />
1. Rescope: By eliminating scope creep, design a new improved scope baseline and<br />
applying common sense to limit the scope for the sake of project success.<br />
<br />
2. Restructure: By examinating the team´s performance, re staff the project accordingly<br />
looking at the whole projects portfolio and organization resources availability.<br />
<br />
3. Reschedule: By analyzing the causes of the delay and&#160;identifying unnecessary or unclear<br />
requirements and&#160;converting them into a smaller feasibility study.&#160;<br />
<br />
4. Kill / Cancel:&#160;With a&#160;politically&#160; sensitive manner decide if a project must die.<br />
A PMO must help to recommend what is best for the company.<br />
<br />
Finally, a PMO will provide a more effective support&#160;if&#160; it early identifies an issue and<br />
does something immediately to change&#160;fundamentally the project that is in trouble.<br />
<br />
JD</p>

]]></description>
			<content:encoded><![CDATA[<div>
<p>In many cases, the PMO´s value is not easy to see. Many Project Managers&#160;say that<br />
the PMOs are only focused on surveillance; watching if the projects are on time and<br />
on budget but when troubles appear, they don´t receive effective support from their PMO.</p>
<p>Gartner has been researching about PMO best practices, and I must say that best practices<br />
to support troubled projects have to be embraced for your PMO in order really make<br />
&#160;a difference adding value to the business and ensure overall success of their projects<br />
portfolio.</p>
<p>The number one action that a PMO has to take is to prevent that their projects fall into<br />
the danger zone, the PMO has to be proactive by periodically check every project for<br />
early warning signs. This check has to be done&#160;with each Project Manager; not using<br />
fancy reporting systems nor e mails but with a simple phone call or a&#160;face to face meeting<br />
&#160;whenever it´s possible. For projects with larger teams at the customer site or involving<br />
tasks in industrial environments where QHSE standards are key to the project success,<br />
the PMO must perform field visits to personally check the project´s health.</p>
<p>Coaching and mentoring the Project Managers will always add more value than acting<br />
as a detective researching why bad things happened&#160;to a project.</p>
<p>But what kind of support a Project Manager needs from his PMO when his project is<br />
&#160;already in trouble?</p>
<p>The PMBOK mentions that only when a project is doomed, a rebaseline should be<br />
performed.</p>
<p>The PMO must have standard processes to perform this project rebaseline to analyze,<br />
decide and&#160;execute the best alternative between:</p>
<p>1. Rescope: By eliminating scope creep, design a new improved scope baseline and<br />
applying common sense to limit the scope for the sake of project success.</p>
<p>2. Restructure: By examinating the team´s performance, re staff the project accordingly<br />
looking at the whole projects portfolio and organization resources availability.</p>
<p>3. Reschedule: By analyzing the causes of the delay and&#160;identifying unnecessary or unclear<br />
requirements and&#160;converting them into a smaller feasibility study.&#160;</p>
<p>4. Kill / Cancel:&#160;With a&#160;politically&#160; sensitive manner decide if a project must die.<br />
A PMO must help to recommend what is best for the company.</p>
<p>Finally, a PMO will provide a more effective support&#160;if&#160; it early identifies an issue and<br />
does something immediately to change&#160;fundamentally the project that is in trouble.</p>
<p>JD</p>
</div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/08/21/effective-pmo-support-for-troubled-projects/feed/</wfw:commentRss>
		</item>
		<item>
		<title>The 40 root causes of troubled projects</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/08/17/the-40-root-causes-of-troubled-projects/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/08/17/the-40-root-causes-of-troubled-projects/#comments</comments>
		<pubDate>Sun, 17 Aug 2008 12:22:26 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[A nice list of root causes of troubled projects...<br />
<br />
Is important to verify this checklist to avoid issues from inititation to closure...<br />
<br />
<a href="http://www.herneconsultants.com/proj40.htm">http://www.herneconsultants.com/proj40.htm</a><br />
<br />
JD
]]></description>
			<content:encoded><![CDATA[<div>A nice list of root causes of troubled projects&#8230;</p>
<p>Is important to verify this checklist to avoid issues from inititation to closure&#8230;</p>
<p><a href="http://www.herneconsultants.com/proj40.htm">http://www.herneconsultants.com/proj40.htm</a></p>
<p>JD
</p></div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/08/17/the-40-root-causes-of-troubled-projects/feed/</wfw:commentRss>
		</item>
		<item>
		<title>THE SPONSOR MUST KNOW THE TRUTH&#8230;..FROM YOU!!!</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/08/17/the-sponsor-must-know-the-truthfrom-you/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/08/17/the-sponsor-must-know-the-truthfrom-you/#comments</comments>
		<pubDate>Sat, 16 Aug 2008 21:37:14 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[There are few things more frustrating than arriving&#160;at your customer site&#160;and find out<br />
that your sponsor is pissed off with you and your company because she/he discovered<br />
&#160;an skeleton in the closet of your project.<br />
<br />
Communication is a primary responsibility of a Project Manager, and sometimes you<br />
&#160;may be caught between a rock and hard place trying to decide if you tell to the Sponsor<br />
&#160;the plain truth about an issue in your project (that probably will impact your company's<br />
profit, in the case of a penalty)&#160;or hide&#160;the issue&#160;hoping that you will fix it&#160;later and you will<br />
&#160;avoid the hard time with your customer and a&#160;profit decrease of your company.<br />
<br />
Well, in my experience, when an issue arise in your project you must identify it, calculate<br />
the consequences that it will bring, find the root cause of the&#160;issue,&#160;design and implement&#160;<br />
corrective and preventive action plans to avoid re-ocurrance and finally have an internal<br />
meeting with the account manager and your direct manager to&#160;decide the message and<br />
the better way to communicate the issue to the Sponsor.&#160;Remember, the Sponsor&#160;*must*<br />
receive that message from you; this will increase your accountability image with the sponsor,<br />
will strenght your relationship with the sponsor by increasing the confidence on your<br />
&#160;professionalism and your position for future negotiations will be way much better.<br />
<br />
And finally, remember, when communicating bad news *never* tell lies but do not<br />
tell all the truth..;)<br />
<br />
JD
]]></description>
			<content:encoded><![CDATA[<div>There are few things more frustrating than arriving&#160;at your customer site&#160;and find out<br />
that your sponsor is pissed off with you and your company because she/he discovered<br />
&#160;an skeleton in the closet of your project.</p>
<p>Communication is a primary responsibility of a Project Manager, and sometimes you<br />
&#160;may be caught between a rock and hard place trying to decide if you tell to the Sponsor<br />
&#160;the plain truth about an issue in your project (that probably will impact your company&#8217;s<br />
profit, in the case of a penalty)&#160;or hide&#160;the issue&#160;hoping that you will fix it&#160;later and you will<br />
&#160;avoid the hard time with your customer and a&#160;profit decrease of your company.</p>
<p>Well, in my experience, when an issue arise in your project you must identify it, calculate<br />
the consequences that it will bring, find the root cause of the&#160;issue,&#160;design and implement&#160;<br />
corrective and preventive action plans to avoid re-ocurrance and finally have an internal<br />
meeting with the account manager and your direct manager to&#160;decide the message and<br />
the better way to communicate the issue to the Sponsor.&#160;Remember, the Sponsor&#160;*must*<br />
receive that message from you; this will increase your accountability image with the sponsor,<br />
will strenght your relationship with the sponsor by increasing the confidence on your<br />
&#160;professionalism and your position for future negotiations will be way much better.</p>
<p>And finally, remember, when communicating bad news *never* tell lies but do not<br />
tell all the truth..;)</p>
<p>JD
</p></div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/08/17/the-sponsor-must-know-the-truthfrom-you/feed/</wfw:commentRss>
		</item>
		<item>
		<title>WELCOME TO THE TROUBLED PROJECTS BLOG</title>
		<link>http://troubledprojectsmanagement.blog.com/2008/08/16/welcome-to-the-troubled-projects-blog/</link>
		<comments>http://troubledprojectsmanagement.blog.com/2008/08/16/welcome-to-the-troubled-projects-blog/#comments</comments>
		<pubDate>Fri, 15 Aug 2008 22:35:21 +0000</pubDate>
		<dc:creator>John Douglas Cabrera</dc:creator>
		
		<guid isPermaLink="false"></guid>
		<description><![CDATA[This blog is intended to share experiencies, best practices, advices and comments regarding<br />
&#160;managing troubled projects.<br />
<br />
As more than 90% of the projects finish behind schedule, have costs overruns or experience<br />
quality issues; it's very important to be aware of what other project managers are doing.<br />
Learn from previous experiences and share pains that we suffered during projects and how<br />
could figured out to resolve them.<br />
<br />
I will be sharing my thoughts, experiences, lessons learned and any other comment that<br />
I may have regarding troubled projects. Your comments, knowledge share and criticism<br />
are very welcome!!<br />
<br />
JD
]]></description>
			<content:encoded><![CDATA[<div>This blog is intended to share experiencies, best practices, advices and comments regarding<br />
&#160;managing troubled projects.</p>
<p>As more than 90% of the projects finish behind schedule, have costs overruns or experience<br />
quality issues; it&#8217;s very important to be aware of what other project managers are doing.<br />
Learn from previous experiences and share pains that we suffered during projects and how<br />
could figured out to resolve them.</p>
<p>I will be sharing my thoughts, experiences, lessons learned and any other comment that<br />
I may have regarding troubled projects. Your comments, knowledge share and criticism<br />
are very welcome!!</p>
<p>JD
</p></div>
<div></div>
]]></content:encoded>
			<wfw:commentRss>http://troubledprojectsmanagement.blog.com/2008/08/16/welcome-to-the-troubled-projects-blog/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
