<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on IT projects fail most often due to organizational issues ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-307438/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-23T01:00:28-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3198315]]></link>
        <description><![CDATA[Because the scope is not well defined.  Because the stakeholders do not understand that the nuances of an IT project must be kept in check.  I often see gold-plating occur from a key sponser.... at a time where it jeopardizes the critical path and puts the project manager in an situation they cannot win.  This is for all projects.... it is the concept of project management itself is not been accepted for the discipline it is.... it is used as an excuse to get funds allocated and pet &quot;incentives&quot; injected after the point of no return.Good project managers struggle with senior managers whose interest that often conflict with the project objective.  This struggle can easily become a slow walk to the unemployment line.The fix is tenacity of purpose by the project managers, combined with a sense of ethics to the PMI that dictates our code.  It is the compromise to powers that can, and often will, derail a career that jeopardizes most projects.  The fix is not easy, but the cause is painfully apparent.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3198315]]></guid>
        <dc:creator><![CDATA[wmkrayer]]></dc:creator>
        <pubDate>Tue, 10 Nov 2009 18:55:17 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3194680]]></link>
        <description><![CDATA[I just got done reading another article about &quot;Think Time&quot; for a single project manager for a single project.  Once you expand it to the level that this article is speaking to you must have not good but great communication between the customer and the consulting group.  I believe that the consulting group should have done a better analysis of the data involved to begin with have sign off from the different regional managers that all the data was present or have an online forum for the EU's to check thier data prior to roll out.  The check process should have been monitored and enforced by the regional managers that signed off on the basic data form to begin with.  Thats my 2 copper]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3194680]]></guid>
        <dc:creator><![CDATA[thrugar]]></dc:creator>
        <pubDate>Wed, 04 Nov 2009 09:37:39 -0800</pubDate>
    </item>
             

    <item>
        <title><![CDATA[SAP]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3077807]]></link>
        <description><![CDATA[I have heard that SAP implementation in itself is a very time consuming project, I actually quit a job because the new director decided that SAP was the way to go. We had devoted extensive research into the project and my opinion was that yes we could continue to do business in the same screwball manner but the implementation would probably kill the company.  I believe this is because by nature SAP tries to make anything work for anybody.  This, ?we can do whatever? software approach can make implementation a nightmare.  I agree that having experience at the helm could have helped keep the boat afloat for a while longer but the choice of SAP, I would bet was the true nail in this coffin. Schools tend to be less organized and automated than one would think.  A more constrictive choice that would have forced them to change the way they do things a little more, and also to rethink their processes, would have had a greater chance of success.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3077807]]></guid>
        <dc:creator><![CDATA[radcliffe@...]]></dc:creator>
        <pubDate>Mon, 18 May 2009 12:33:00 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Did they tell you why they refused?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3070342]]></link>
        <description><![CDATA[Did they give you any reason why they refused besides the fact that it's additional work? I love to write small utilities for my clients if they mention they're willing to vet some testing on their own. It's amazing how much time is saved when we both come to the table prepared to discuss the specifics of troubling items.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3070342]]></guid>
        <dc:creator><![CDATA[Bad Boys Drive Audi]]></dc:creator>
        <pubDate>Wed, 06 May 2009 12:45:41 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Amen to that!]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3069661]]></link>
        <description><![CDATA[We had an interface problem that baffled the software developers. They finally agreed to work with me on the problem.  Sat down for half an hour with the programmer and we had the problem solved!  I begged them for some small test utilities, they refused. I had to write them myself.We are drowning in a sea of CMMI, requirements people, and process.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3069661]]></guid>
        <dc:creator><![CDATA[mdarsman42@...]]></dc:creator>
        <pubDate>Tue, 05 May 2009 12:53:49 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3066303]]></link>
        <description><![CDATA[Based on this article only, I would say that organizational aspects causes more failure. And then again, it appears that this was money politics here.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3066303]]></guid>
        <dc:creator><![CDATA[njackson@...]]></dc:creator>
        <pubDate>Thu, 30 Apr 2009 05:33:46 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Learn from mistakes]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065935]]></link>
        <description><![CDATA[I don't necessarily agree that the PM has to be too technical. Technical to a degree yes, but if you are managing a project with 10,000 tasks and 500 team members, how can you know every technical aspect? I think it is important to learn from past mistakes. PMs especially should read case studies and blogs to keep up with failed projects and most importantly, remember why they failed. Find patterns, because there are usually patterns. Then gleam knowledge from those patterns.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065935]]></guid>
        <dc:creator><![CDATA[Maxfli82]]></dc:creator>
        <pubDate>Wed, 29 Apr 2009 16:20:29 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065730]]></link>
        <description><![CDATA[&quot;Organizational Issues&quot; is a pretty broad brush.  Lack of training, funding, etc are all &quot;Organizational Issues&quot;.  However I do agree that technical issues are rarely the problem.  The problems revolve around the current notion of a project manager.  Especially the notion that the PM needn't be &quot;technical&quot;.  The only effective PMs that I have ever seen knew everyone's job better than the persons holding them and had absolute authority over the consultants and the clients.  If the PM can't detect BS answers and can't punish those who give them then on-time, on-budget projects will be random occurrences.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065730]]></guid>
        <dc:creator><![CDATA[BogMeadow]]></dc:creator>
        <pubDate>Wed, 29 Apr 2009 11:46:53 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Still Try to Block and Undermine]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065372]]></link>
        <description><![CDATA[What you say is true Chief Alchemist.  Unfortunately even with all these elements in place, there are still some co-workers who actively or passively block or undermine projects.I can empathize that they feel threatened that their status in the office will change or they will &quot;lose power&quot;.  The inability to see the big picture is maddening, still.  If the project or company fails or does poorly, then how safe is their job?  Hard to play silly games from the unemployment line.Luckily, these types of people are in the minority.  Most employees are professional and mature enough to do good work and do their best to contribute to any success.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065372]]></guid>
        <dc:creator><![CDATA[Devans00]]></dc:creator>
        <pubDate>Wed, 29 Apr 2009 07:03:29 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Lockheed Martin and the MTA]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065248]]></link>
        <description><![CDATA[Here is quite a tale.  Lockheed has filed a lawsuit asking it to be released from a $250 million contract with the New York City MTA.  Project was to be a post September 11 implementation of over 2000 cameras at critical junctions.  A project from hell.Courtesy of the MTALockheed has been denied a schedule of access to East River tunnels.Rooms for computer equipment are not empty YET and some show extensive sign of water damage.Of 2000 cameras that were to be working LAST YEAR, only 300 are actually up and running.Now the fault can be blamed on both side at the time of this writing, but given the current state of the MTA .... probably 80% their fault here.Read this and weep.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065248]]></guid>
        <dc:creator><![CDATA[reisen55@...]]></dc:creator>
        <pubDate>Wed, 29 Apr 2009 05:31:41 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I implemented a new and much more accurate]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065242]]></link>
        <description><![CDATA[system for collecting reasons for delays in a manufacturing process.I got told there was something wrong with my work, because the number of minutes delayed went up and the amount of production per available minute went up as well.Took me ages to explain either they were under reporting before or over reporting now.I'm positive they were massaging the figures to look better. Mill manager wanted to check my math!One of the first systems I worked on was replacing the a manual system for recording how much stuff got returned by the customer and why. That went up as well. Not due to accuracy, but because the manual system only reported those customers who complained in that month in it's year to date figures....Quite strangely once the real figures started getting reported, some of the issues got resource and our customers, started to like us a bit more. The sudden jump in complaints was considered highly suspicious, as though IT had again f'ed up...]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065242]]></guid>
        <dc:creator><![CDATA[Tony Hopkinson]]></dc:creator>
        <pubDate>Wed, 29 Apr 2009 04:29:19 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065033]]></link>
        <description><![CDATA[Absolutely true. The most ridiculous complaint I have ever heard: the Accounting manager telling me (very angrily) that I was trying to pull the carpet off his feet because I was trying to automate his area, which was so full of innacuracies and inconsistent information among other things.Another one, a CFO (of a small business company) asking me to implement a combo box on a data entry screen only to choose numbers 1, 2, or 3. She could not tell me (she didn't want to) what those numbers were for, I just had to deliver it and that was it.It's a shame that our country is trying to move thru 21st century with such a bunch of dinosaurs still with the reins in their hands.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3065033]]></guid>
        <dc:creator><![CDATA[HighTechAngel]]></dc:creator>
        <pubDate>Tue, 28 Apr 2009 18:43:31 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[How to assess potential IT failure...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3064629]]></link>
        <description><![CDATA[Say there are two scales (among many) to evaluate a person's abilities1. Scale of Correctness of Knowledge and Understanding2. Scale of Persuasiveness and AuthorityScale 1 goes like: top&gt; knows all ... knows he doesn't know, doesn't know he doesn't know, doesn't even suspect   word is gospel ... make sure he's right, never right, always wrong bottomIgnoring duplicity, IT projects fail when the leaders (or any influential persons) ratios are inappropriately higher on 2 that justified by 1.Don't believe me, check it out.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3064629]]></guid>
        <dc:creator><![CDATA[keepitsimpleengineer@...]]></dc:creator>
        <pubDate>Tue, 28 Apr 2009 09:55:55 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[No Doubt about it!!]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3064659]]></link>
        <description><![CDATA[Having been the lead on a few IT projects, I've seen organizational issues doom projects right from the start. Of primary importance is Executive support and stakeholder buy-in. I'm referring primarily to large projects of course. Second, is cultural change, the project management, then the tech stuff. I wouldn't agree that the exec stakeholder need understand the complexities of technology. That really doesn't matter. What does matter is that the project lead and subordinate team leaders know internal processes, procedures and requirements. If you don't know what you have, and what you do everyday, then how will you apply this to the new system?Also, people need to be held accountable for deliverables. Often times, some team members may not have that same sense of urgency you may have. Lastly, a phased implementation in this particular case would have made much more sense, rather than cutting loose all of your old systems for one new one. Test, Test, test I say! ]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3064659]]></guid>
        <dc:creator><![CDATA[sermic]]></dc:creator>
        <pubDate>Tue, 28 Apr 2009 09:47:46 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[I agree ...]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063712]]></link>
        <description><![CDATA[Ho Ho Ho - I do agree with you by the way - the focus of a good PM should be on assembling a team of -experts- and not trying to do everything solo.  Something about ego?  PM should have good organisational, and communication skills, with perhaps an emphasis on listening skills.Learn to identify the champions, provide them with opportunity, and you'll get to be one yourself!!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063712]]></guid>
        <dc:creator><![CDATA[mwmentor@...]]></dc:creator>
        <pubDate>Mon, 27 Apr 2009 07:04:22 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063686]]></link>
        <description><![CDATA[I have yet to meet a pm system that really works - there are inevitable delays to any project that affects either the deliverable or delivery date.  I think that the primary task of any project management is learning to manage client expectations in business terms which usually boils down to expense/return at the end of the day.I have a friend who has the beginnings of something that I like - he never puts an overall delivery date on his projects - he works it task-by-task.  Seems to keep the client happy most of the time.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063686]]></guid>
        <dc:creator><![CDATA[mwmentor@...]]></dc:creator>
        <pubDate>Mon, 27 Apr 2009 06:51:16 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063221]]></link>
        <description><![CDATA[I agree totally. I am currently experiencing the implementation of a new network management IT system where I work and first and foremost you must get your buy-in or blessing from higher echelon before even thinking about moving forward with the project. Without an IT knowledgeable leader they will never fully understand what you are proposing or the benefits of the new system against the legacy system. You must have management dedicated to the success of the project or it will be doomed from the start. Organizational culture will also play a big part on the success of a IT project. If your legacy system has been around for many years and a lot of time and effort has been put into upgrades, improvements and tweakings plus you still have many of the same employees maintaining this system then you are taking away from them something they now very well and throwing them into the unknown. I believe change is a positive thing and when you have full support from management to back you up and employees are notified well in advance, kept informed, properly trained, provide feedback and feel like they are key players in the implementation of the new system (which they are) then more IT projects won`t just die or be subject to constant scope creep which can greatly increase the cost of the project.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063221]]></guid>
        <dc:creator><![CDATA[bygcee2000@...]]></dc:creator>
        <pubDate>Sun, 26 Apr 2009 05:57:20 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063071]]></link>
        <description><![CDATA[One could suggest that they fail due to 'people' issues.  The most painful, and the most rewarding, part of project management.  The 'project' part of the title 'PM' is pretty easy - ticks in boxes - methodology up the wazoo.  But the 'management' element - to quote Borat - 'this one, not so much'.  Leadership is where the gap is - IMHO.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3063071]]></guid>
        <dc:creator><![CDATA[squolth@...]]></dc:creator>
        <pubDate>Sat, 25 Apr 2009 15:03:39 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[when is a business decision really a technical decision, and vice versa?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3062980]]></link>
        <description><![CDATA[My project management experience taught me that this is a critical issue in most IT projects.  When executives with little IT experience pick platforms, languages, tools, and timeframes without listening to their technical experts. When technical people make decisions about business requirements or data conversions specs (in the absence of direction from the business) -- trouble is not far behind. An IT project is really a business project being implemented using IT technology.  When the business side abdicates, and lets the technical folks make business decisions (which is all too often the case), the results is not &quot;as expected&quot; -- because expectations were not clarified. When technical people choose really new technology, it may be great for their resumees but not so wonderful for the business if they pick the wrong horse in the technology race. Basically, organizational problems are at the root of this set of problems.  All parties must be clear on the business and technical impact to the organization of the decisions made.  Sharing responsibility among groups is an organizational problem that needs to be tackled to make any project (IT or otherwise) more successful.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3062980]]></guid>
        <dc:creator><![CDATA[mhwallace01@...]]></dc:creator>
        <pubDate>Sat, 25 Apr 2009 07:43:43 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: IT projects fail most often due to organizational issues]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3062951]]></link>
        <description><![CDATA[&quot;Do organizational aspects of a project cause failure more than the technical ones?&quot;Hmmmm. Certainly these organizational aspects do have a major impact.  Especially when dealing with any significantly large organization.  Made worse when said organization consists of many disparate and diverse subgroups with specialty functions/missions.  And when the organization has, over time, absorbed other formerly independent groups.What's new about this?You have departmental jealousies and competitiveness with each other, this or that group clamoring for the most attention or exercise of power.  Special groups who'd formerly been able to operate pretty much as they pleased who're now being told they must toe the line, conform, and operate in some standard fashion.  Groups that were formerly independent of the parent organization, but which have now been absorbed by it.  The employees and personnel in such formerly independent groups having done what they did, the way they did it, for many years previously ... perhaps very successfully so. So on and so forth.I've seen this many a time.  When I worked for a major telecom that corporation actually consisted of what had formerly been dozens of previously independent, smaller telecoms.  Each having formerly had their own rules, their own methods, and their own cultures.  Getting all of them moving in the same direction, following the same rules, etc was pretty much like trying to herd a pack of cats.The same applies to where I work now. &quot;The Company&quot;, consists of what were formerly several smaller companies.  Who're pretty much integrated now, following the same rules and procedures, but it wasn't easy or quick to accomplish.When I deal with our customers, all very sizable organizations, I quite expect that there will be communications and misunderstanding issues between this subgroup and that.  That on any particular project you'll meet foot dragging and resistance, disagreements, and someone getting his or her skivvies in a bunch, and one or more who'll try his or her best to claim that some exception be made, or that such and such should be changed, or whatever. Just part of doing business.In such cases I'm pleasant, I listen, I take notes ... and then tell whomever that he or she must take the matter to &quot;The Big Boss&quot;.  That being whomever it is within the organization that's in charge of overseeing the project ... and signing the check that'll pay us.  In the meantime, I'm following the plan as written and signed by the parties concerned.Yah can't please everybody, and I don't even try.  I go by what the contract says.  Until whoever has the authority to do so amends the contract.  And that's gonna cost em.Too many efforts made to modify and amend the contract? We're likely to put a halt to that.  Tell customer to forget it.  Or, wait until the current contract as written is complete and online and running.  And THEN we'll address the subject of making changes.Of course, sometimes whoever is in charge ... isn't all that good at what he or she does.  And has trouble dealing with the folks I direct his or her way. i.e. Not so good at saying &quot;No&quot;, or &quot;We'll deal with that later.&quot;  But that's the customer organization's problem.Sometimes, when &quot;The Big Boss&quot; is having trouble with his or her spine, we help him or her out.  We have had times when we've brought our own lawyers into play, and had them explain in polite legalese that if this or that mid-project revision is insisted upon, we believe that the project is in jeopardy, now would you kindly sign this piece of official looking paper which absolves us of all responsibility and blame?Or we just look at the mid-project revision, say we'd be happy to accommodate them .... here is the price tag.  And we make sure the price tag is so stiff that somebody reading it is gonna faint on the spot.As contractors, we bear some responsibility for managing not only the work being done, but also the contract.  Letting a customer steamroll over you, insisting upon addendum's, modifications, exceptions, and so forth willy-nilly is a great way to have a failed project and/or lose your a**.I'm not sure that in the example case you cite that the problem was that the guy wasn't technically savvy.  I think it might be more of a case that his management skills were not up to the task, and/or the school district did not give him the power and authority he needed.I deal with schools districts all the time, my bet would be that the later case was the most likely.Dealing with school districts is always problematical, anyway.  Too few people within them have any true understanding of economics, business, money management, and so forth.  And too many PhD's in this or that, who think that because they're expert in something, they're expert in everything.I'm not exaggerating in my last comment.  I wouldn't even be able to remember how many times I have the conversation where some school official asked for or demanded this or that.  To which I replied something to the effect that it was infeasible, wouldn't work, wouldn't actually solve the problem, or whatever.  Just to have that person employ words to the effect of implying I wasn't qualified to question his or her judgment/knowledge/decision.Chuckle, one particularly troublesome PIA once swelled up, turned red in the face, and reminded me that she had NOT ONE, but TWO PhD's and felt she was quite qualified to tell me I was wrong and her solution was better.  ROFLMAO ... at the time we were discussing an issue about which she'd already established, via things she had said, that she did not know as much about it as a first year student in the subject.I refrained from calling her dumber than a rock.  But it was what I was thinking.  I just resorted to my old standby. &quot;Madam, THIS is the way it is going to be. As per the contract.  If you have an issue with that, please take it up with the District's manager in charge of overseeing the contract and it's completion.&quot; and I handed her a card with his name on it and walked out.  Later that fellow, after she'd had her chance to vent at him, make her demands, and so forth called me up and called me a SOB.  Politely.  With a big sigh at the end of it.  And expressed his pleasure in the fact that he only had a year to go until retirement.  Oh, he'd not bent to her will.  But he was sure hearing about that. Besides the fact that she was a major department head, she had a close alliance with numerous key players in the school district (a large one with a couple billion bucks in annual funding).  And he'd had to defend his decision to not let her have her way repeatedly.  And in some cases, heatedly.We still do business with that school district.  In the end the performance of our services has met or exceeded all their contract requirements.  So that lady and I do upon occasion have our paths cross.  When that happens, I smile, am polite, wish her a good day, etc.  She ignores me as if I don't exist.&quot;The trouble was apparent from the first month the new software went live. Some teachers were underpaid, some overpaid and some had their names completely erased from the system.&quot;The trouble I have here is that I have seen, and experienced this precise problem.  Numerous times, within numerous organizations.  Happened when I was in the Navy (I retired from that service) several times as they changed their pay and accounting systems.  Happened a couple times after I retired from the Navy and worked for a major telecom for 10 years.  Has happened once since I started working for my current employer as they switched over their software.Know of it having happened in numerous other organizations that friends and family have worked for.So what's new?Is it being suggested that it's not ever really the IT people's problem or failure?Give me a break.BOTH sides have significant culpability and responsibility for such failures.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307438-3062951]]></guid>
        <dc:creator><![CDATA[Osiyo53@...]]></dc:creator>
        <pubDate>Sat, 25 Apr 2009 06:03:55 -0700</pubDate>
    </item>
    </channel>
</rss>

