<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:georss='http://www.georss.org/georss' xmlns:gd='http://schemas.google.com/g/2005' xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-36675398</id><updated>2011-09-26T12:13:06.001-04:00</updated><category term='Root Cause'/><category term='PM Practices'/><title type='text'>American Eagle Group Project Management Nuggets</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://pmnuggets.ameagle.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/36675398/posts/default?max-results=100'/><link rel='alternate' type='text/html' href='http://pmnuggets.ameagle.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><author><name>American Eagle Group</name><uri>http://www.blogger.com/profile/16537769716271296868</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='31' height='32' src='http://3.bp.blogspot.com/_W84pPcCcy7E/SUffESq0oxI/AAAAAAAAABE/65n5-gIubKU/S220/AElogo_small.gif'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>2</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>100</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-36675398.post-8377880903434624188</id><published>2008-09-10T15:45:00.007-04:00</published><updated>2011-02-04T00:05:15.525-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='Root Cause'/><category scheme='http://www.blogger.com/atom/ns#' term='PM Practices'/><title type='text'>When Solving A Problem, Get To The Root Cause, Don’t Redefine The Symptom</title><content type='html'>&lt;table border="0" cellpadding="0" cellspacing="0" style="width: 400px;"&gt;&lt;tbody&gt;&lt;tr&gt;&lt;td align="middle" valign="bottom" width="88"&gt;&lt;a href="http://www.zimmerspeaks.com/" target="_blank"&gt;&lt;img alt="David A. Zimmer" border="0" height="100" src="http://www.ameagle.com/images/Zimmer_head_100x100.gif" width="88" /&gt;&lt;/a&gt;&lt;/td&gt;&lt;td align="left" style="font-family: trebuchet ms;" valign="bottom" width="198"&gt;&lt;div class="style1"&gt;&lt;a href="http://www.zimmerspeaks.com/" target="_blank"&gt;David A. Zimmer, PMP&lt;/a&gt;&lt;br /&gt;Chief&amp;nbsp;Project Professor&lt;br /&gt;&lt;a href="http://www.ameagle.com/" target="_blank"&gt;American Eagle Group&lt;/a&gt;&lt;/div&gt;&lt;/td&gt;&lt;td align="middle" valign="top" width="50"&gt;&lt;a href="javascript:window.print()"&gt;&lt;img alt="Print" border="0" height="25" src="http://www.ameagle.com/images/Print.gif" width="50" /&gt;&lt;/a&gt;&lt;/td&gt;&lt;td align="middle" valign="top" width="50"&gt;&lt;a href="http://www.ameagle.com/podcasts/ITProjectRootCause.mp3"&gt;&lt;img alt="Listen Now" border="0" height="25" src="http://www.ameagle.com/images/ListenNow.gif" width="50" /&gt;&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/tbody&gt;&lt;/table&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;span style="color: black;"&gt;I recently read an article appearing in CIO Magazine titled “&lt;/span&gt;&lt;a href="http://www.cio.com/article/440721/Common_Project_Management_Metrics_Doom_IT_Departments_to_Failure?contentId=440721&amp;amp;slug=&amp;amp;source=nlt_cioinsider" target="_blank"&gt;&lt;span style="color: #3333ff;"&gt;Common Project Management Metrics Doom IT Departments to Failure&lt;/span&gt;&lt;/a&gt;&lt;span style="color: black;"&gt;” where the subtitled mentioned a report by &lt;/span&gt;&lt;a href="http://www.forrester.com/rb/research" target="_blank"&gt;&lt;span style="color: #3333ff;"&gt;Forrester Research&lt;/span&gt;&lt;/a&gt;&lt;span style="color: black;"&gt; stated the metrics used to measure IT project success influences the perceptions of failure. It goes on to say that we need to change to increase the perception of success instead.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;We’ve all heard the adage “perception is fact” implying perception is not fact, it only has the allusion to be factual. I don’t know if it is my sense of humor, but the statement of “increase the perception of success” was strangely funny. Did it mean the project was actually a failure but we make it appear successful? Does it harken to another well-tread cliché, “In project management, we simply redefine the parameters and declare victory. That’s how we have successful projects!”&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;The article further details four things the PMO can do to help increase the perception of success. While I agree with them:&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;/span&gt;&lt;br /&gt;&lt;ul&gt;&lt;li&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;span style="color: black;"&gt;keep project steering committee on task,&lt;/span&gt;&lt;/span&gt;&lt;/li&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;li&gt;&lt;span style="color: black;"&gt;improve communication with project sponsor about changes,&lt;/span&gt;&lt;/li&gt;&lt;li&gt;&lt;span style="color: black;"&gt;improve reliability of project plans, and &lt;/span&gt;&lt;/li&gt;&lt;li&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;span style="color: black;"&gt;better communicate estimates of costs, schedule and resources;&lt;br /&gt;&lt;/span&gt;&lt;/span&gt;&lt;/li&gt;&lt;/span&gt;&lt;/ul&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;span style="color: black;"&gt;I believe they miss the fundamental basics of the problems – the root causes.&lt;br /&gt;According to the &lt;/span&gt;&lt;a href="http://www.standishgroup.com/" target="_blank"&gt;&lt;span style="color: #3333ff;"&gt;Standish Group&lt;/span&gt;&lt;/a&gt;&lt;span style="color: black;"&gt;, IT projects have only a 29% chance of succeeding. You would think with the advance in technology, the development of quality processes and increase of understanding humans; we’d have a better shot of being successful. In 2003, the Standish Group estimated we spent $382 billion on IT projects in the US alone. They further stated $82 billion was an outright waste. Using the 71% failure rate, we spent $271 billion on failed projects. Maybe that’s why we need to increase the perception of success – so we can balance the books!&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Based upon my years of managing IT projects (I’ll admit, not all were successes, perceived or otherwise) and experience training more than a thousand people in the art of project management, I believe the following are the root causes for IT project failures.&lt;br /&gt;&lt;br /&gt;&lt;/span&gt;&lt;span style="color: #3366ff;"&gt;&lt;strong&gt;1. Project managers are chosen, not trained.&lt;/strong&gt;&lt;/span&gt;&lt;/span&gt;&lt;span style="color: #3366ff;"&gt;&lt;br /&gt;&lt;/span&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;In my training seminars, I ask how many people actually chose project management as a career. I have had only three people raise their hands. Usually, we are selected because we are doing well in our “real” jobs and seemed to be organized getting things done. One day, as we arrive in our office, twang, we are dubbed project managers. No training.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Then I ask how many have any sort of formal training in managing projects. Regardless of the industry, the percentage is basically the same, only 20% have had any form of training. I reduce the definition of training to the ridiculous of a one hour discussion and very few additional hands go up. Only 5% have more than a day and 1% go on to be certified through &lt;/span&gt;&lt;a href="http://www.pmi.org/" target="_blank"&gt;&lt;span style="color: #3333ff;"&gt;Project Management Institutes’&lt;/span&gt;&lt;/a&gt;&lt;span style="color: black;"&gt; Project Management Professional certification.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;It is not we aren’t intelligent and can’t learn the ropes, but usually we learn by observing others who have gone before us. They learned the same way – by observing others. As a result, improper methods are learned and used rather than industry accepted practices. We just &lt;em&gt;gitter dun&lt;/em&gt; – whatever it takes, nights, weekends, extra shifts, Herculean efforts – we &lt;em&gt;gitter dun&lt;/em&gt;. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;As a result, we don’t put the proper measures in place to give the information business people need. Worse, we really don’t know where we stand in our own projects. We can’t repeat our successes because we don’t know what we did to be successful. We don’t always learn from our mistakes so we are doomed to repeating them. And finally, many projects we considered successful really weren’t causing us to repeat bad habits because we believe they are good practices.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Through training, we learn proper techniques, why certain processes should be followed and the tools we need as project managers. To contrast untrained project managers with a failure rate of 71%, studies have shown using trained and certified project managers – PMPs specifically – succeed close to 75% of the time. &lt;/span&gt;&lt;br /&gt;&lt;br /&gt;&lt;em&gt;&lt;span style="color: black;"&gt;&lt;strong&gt;Root cause #1:&lt;/strong&gt; project managers aren’t trained to do the job we ask.&lt;/span&gt;&lt;/em&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;strong&gt;&lt;span style="color: #3366ff;"&gt;2. No formal change process in place to determine success or failure.&lt;/span&gt;&lt;/strong&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;In the CIO magazine article, someone placed a comment contrasting construction project management with IT project management. He stated IT methods are primitive to constructions processes. I agree totally. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;First, construction follows a methodical, time-proven method. They work from blueprints with every detail shown. They research the site and understand what lies hidden before digging. They understand the necessary inventory of materials and labors in advance of the start date. But most importantly, they have a change process. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Once the deal is signed, any changes to the agreement require a change order with signatures. The change order details the impacts to schedule, increase to budget, amendment to the project scope, etc. Each party must sign before the change occurs, otherwise, the original plan holds. No changes are made unless the boss says so.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;In IT, we take a different tack. Again, from my survey of many attendees, only three or four people stated their company had a formal change form and process. Worse, they reported changes to the project can come from any where through any channel to any member of the project team. Since many things are considered “easy,” the impact to the rest of the project and beyond is never considered. If a change is formally documented, no one dares sign it. Accountability is forbidden. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;As a result, what is defined to be the project is not really the project. As time passes, changes are requested but not tracked. The project morphs and twists into something other than the original definition. As a result, the original project may have been successful using the traditional metrics, but no one can prove it because no clear definition of the project exists.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Additionally, changes come through various portals. There might be a formal request sent from the CIO to the IT project manager. Another request comes from the sales manager tapping someone on the shoulder in the hallway. A third and most insidious is the IT staffer who “sees something needs to be done, and does it” without tracking the impact to the overall project. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Solution for such a situation is two-fold: a well defined and followed project scope and a formal method for requesting changes.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;em&gt;&lt;span style="color: black;"&gt;&lt;strong&gt;Root cause #2:&lt;/strong&gt; No formal change process which defines a single point to funnel change requests.&lt;/span&gt;&lt;/em&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;strong&gt;&lt;span style="color: #3366ff;"&gt;3. Project Expectations Not Defined In Detail&lt;/span&gt;&lt;/strong&gt;&lt;/span&gt;&lt;span style="color: #3366ff;"&gt;&lt;br /&gt;&lt;/span&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;A successful project must meet the expectations of the stakeholders. Even if it comes in on budget and on time, if it doesn’t meet their expectations, it failed. Unfortunately, we don’t document the expectations. We document the technical requirements, the inventory list of hardware and software needed, select the team of implementers, etc., but we don’t seem to jot down the expectations.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;If we don’t document the expectations, how do we know when we are finished? If the expectations are met, we would have success by definition, correct?&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;Of course, the stakeholders don’t always reveal their expectations for us to conveniently document. In fact, their expectations change over the course of the project. Even if we met the original expectations, we still fail because we didn’t meet the current list of desires.&lt;br /&gt;As a result, project managers must spend a good deal of time understanding the stakeholders’ motivations, desires, intents, and rationale for the project. Periodically, he must check in with the stakeholders to verify current understanding of their needs and make adjustments accordingly.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;em&gt;&lt;span style="color: black;"&gt;&lt;strong&gt;Root cause #3:&lt;/strong&gt; lack of understanding expectations leading to no formal documentation listing motivations, desires, intents, etc. of stakeholders.&lt;/span&gt;&lt;/em&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;strong&gt;&lt;span style="color: #3366ff;"&gt;Conclusion&lt;/span&gt;&lt;/strong&gt;&lt;/span&gt;&lt;span style="color: #3366ff;"&gt; &lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;I don’t feel it is right to simply change the perception of IT project success. To me, that’s cheating and we don’t solve the real issues. We need to change how we “do” IT project management to be successful. Proper training is key number one. I, like many, managed many projects before I was formally trained. Boy did I learn about my bad habits and improper ways of managing projects. As I instruct others these days from my lessons learned, I see the same transformation in them. &lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;IT doesn’t have to suffer the fate of poorly run, failing projects. Solving the root causes for those problems would go a long way in better return on investments, fewer dollars wasted, and happier IT people. Once these are fixed, we can begin to work on the list from the CIO article.&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;span style="color: black; font-family: 'trebuchet ms';"&gt;&lt;br /&gt;&lt;span style="color: black;"&gt;American Eagle Group offers a series of project management seminars to equip your project managers with the proper knowledge, processes and tools to be successful. Seminars include&lt;br /&gt;&lt;/span&gt;&lt;/span&gt;&lt;br /&gt;&lt;ul style="color: black; font-family: trebuchet ms;"&gt;&lt;li&gt;&lt;span style="color: #3366ff; font-weight: bold;"&gt;PM Boot Camp&lt;/span&gt; - 5-day intensive training covering all aspects of project management. Qualifies for the PMI 35 educational hours needed for the PMP certification.&lt;/li&gt;&lt;li&gt;&lt;span style="color: #3366ff; font-weight: bold;"&gt;PMP Exam Prep&lt;/span&gt; - 2-day overview of PMBOK in preparation for the PMP certification exam.&lt;/li&gt;&lt;li&gt;&lt;span style="color: #6666cc; font-weight: bold;"&gt;&lt;span style="color: #3366ff;"&gt;MS Project 2003&lt;/span&gt; &lt;/span&gt;- Highly effective 2-day seminar teaching basic and advanced topics. Teaches the 9 steps to practical project plans and the 7 Cardinal Rules of MS Project&lt;/li&gt;&lt;li&gt;&lt;span style="color: #3366ff; font-weight: bold;"&gt;MS Project 2007&lt;/span&gt; - Same seminar as the MS Project 2003 also highlights the differences between 2003 and 2007 plus ties it to the industry standard PMI practices.&lt;/li&gt;&lt;/ul&gt;&lt;span style="color: black; font-family: 'trebuchet ms';"&gt;To learn more, send an email to &lt;/span&gt;&lt;a href="mailto:%20info@ameagle.com" style="color: #3366ff; font-family: trebuchet ms;"&gt;info@ameagle.com&lt;/a&gt;&lt;span style="color: black; font-family: 'trebuchet ms';"&gt;. &lt;/span&gt;&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/36675398-8377880903434624188?l=pmnuggets.ameagle.com' alt='' /&gt;&lt;/div&gt;</content><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/36675398/posts/default/8377880903434624188'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/36675398/posts/default/8377880903434624188'/><link rel='alternate' type='text/html' href='http://pmnuggets.ameagle.com/2008/09/when-solving-problem-get-to-root-cause.html' title='When Solving A Problem, Get To The Root Cause, Don’t Redefine The Symptom'/><author><name>American Eagle Group</name><uri>http://www.blogger.com/profile/16537769716271296868</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='31' height='32' src='http://3.bp.blogspot.com/_W84pPcCcy7E/SUffESq0oxI/AAAAAAAAABE/65n5-gIubKU/S220/AElogo_small.gif'/></author></entry><entry><id>tag:blogger.com,1999:blog-36675398.post-116537737874034552</id><published>2006-12-05T22:45:00.004-05:00</published><updated>2011-02-04T00:05:25.882-05:00</updated><category scheme='http://www.blogger.com/atom/ns#' term='PM Practices'/><title type='text'>Project Management - Like crossing the street</title><content type='html'>&lt;table border="0" cellpadding="0" cellspacing="0" style="width: 400px;"&gt;&lt;tbody&gt;&lt;tr&gt;&lt;td align="middle" valign="bottom" width="88"&gt;&lt;a href="http://www.zimmerspeaks.com/" target="_blank"&gt;&lt;img alt="David A. Zimmer" border="0" height="100" src="http://www.ameagle.com/images/Zimmer_head_100x100.gif" width="88" /&gt;&lt;/a&gt;&lt;/td&gt;&lt;td align="left" style="font-family: trebuchet ms;" valign="bottom" width="198"&gt;&lt;div class="style1"&gt;&lt;a href="http://www.zimmerspeaks.com/" target="_blank"&gt;David A. Zimmer, PMP&lt;/a&gt;&lt;br /&gt;Chief&amp;nbsp;Project Professor&lt;br /&gt;&lt;a href="http://www.ameagle.com/" target="_blank"&gt;American Eagle Group&lt;/a&gt;&lt;/div&gt;&lt;/td&gt;&lt;td align="middle" valign="top" width="50"&gt;&lt;a href="javascript:window.print()"&gt;&lt;img alt="Print" border="0" height="25" src="http://www.ameagle.com/images/Print.gif" width="50" /&gt;&lt;/a&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/tbody&gt;&lt;/table&gt;&lt;br /&gt;Recently while giving a presentation to a potential client, I used an analogy of crossing the street. I said:&lt;br /&gt;&lt;br /&gt;"Project management is a lot like crossing the street. You can listen to others who have gone that way before and heed their advice. Look both ways, make sure the way is clear and cross before oncoming traffic hits you. Or, you can simply jump out into the street and see what hits you and then deal with the issues that arise."&lt;br /&gt;&lt;br /&gt;Sadly, too many people and companies people take the latter approach. From our study conducted in January and February 2006, we learned that 76% of project managers are not formally trained in project management. They are intelligent people, probably very good at what they were trained to do. But somehow, they were volunteered to manage a project and were not given the training to do the job properly. As a result, they stuggled to make the project a success.&lt;br /&gt;&lt;br /&gt;Experience shows that even though you are confident in what you are doing, it is always good to have someone watching your back and helping in areas that are new, even though they look very similar to the past. I learned this lesson, almost to my demise, while crossing a street in England. I was ready to cross a road, had my foot off the edge, when I was quickly yanked back to the curb. I was indignant at the person who would do such a thing. I had looked and the way seemed to be clear. I had successfully crossed many streets in my life. But just as I was going to say something to the person who yanked me, a car went whizzing by me and nearly clipped me. I had looked the wrong way! It would have been a fatal mistake. Another perspective on the situation saved my life. My indignation turned into gratefulness.&lt;br /&gt;&lt;br /&gt;American Eagle Group provides that extra perspective. We have crossed many streets successfully - not always without incident though. We have the scars to prove it! Through our "coaching" services, we help you make more informed decisions. We help you see the way more clearly.&lt;br /&gt;&lt;br /&gt;One of our clients used our service and saved over $5 million dollars! They were embarking on a new marketing campaign. They wanted us to provide a sanity check on the project plan and roll-out. While the intent was to make sure the "project management" was sane, our understanding of the market and the broader scope helped us to show them the fallacy of their thinking. Yes, we could have helped them manage their project successfully, but our greater understanding of project management show us that the stakeholders' expectations would not have been met properly - a successful launch of the product and the wise use of $5 million. The project would have been a failure and a waste of the valuable $5 million.&lt;br /&gt;&lt;br /&gt;Another client asked us to determine how they would make money from a particular project. The project had already been underway for two years with more to follow. The annual budget for the project to date was $90 million ($180 M total) with increased budgets to come. So it was critical to understand the profit potential for such a project. After careful analysis of the business plan, we determined that expenses on the project were 77% of the potential revenue. That 77% of the revenue represented operation expenses and did not include the overhead of the ongoing development of the project or other corporate overhead! As a result, the project would never had made any money. We recommended that the project be cancelled based upon the financial analysis.&lt;br /&gt;&lt;br /&gt;We felt like that person who saved my life in England by yanking me back from a speeding car coming for a direction I was not looking. These are just two examples of times when people, confident in what they were doing, looking the wrong way when something was coming from the other direction. We were there to help save them from certain disaster.&lt;br /&gt;&lt;br /&gt;So, the next time you wade out into the street, make sure someone is watching your back!&lt;div class="blogger-post-footer"&gt;&lt;img width='1' height='1' src='https://blogger.googleusercontent.com/tracker/36675398-116537737874034552?l=pmnuggets.ameagle.com' alt='' /&gt;&lt;/div&gt;</content><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/36675398/posts/default/116537737874034552'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/36675398/posts/default/116537737874034552'/><link rel='alternate' type='text/html' href='http://pmnuggets.ameagle.com/2006/12/project-management-like-crossing.html' title='Project Management - Like crossing the street'/><author><name>American Eagle Group</name><uri>http://www.blogger.com/profile/16537769716271296868</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='31' height='32' src='http://3.bp.blogspot.com/_W84pPcCcy7E/SUffESq0oxI/AAAAAAAAABE/65n5-gIubKU/S220/AElogo_small.gif'/></author></entry></feed>
