[Bump to top - any more good stories out there? ] The IT Skeptic's new book Owning ITIL® is out now. The first ten people who contribute an accepted ITIL project horror story get a free copy of the book.
Tell us your horror story here. We will send you a copy of the book.
Rules:
Add the story as a comment on this page
If you do not identify yourself you won't get a copy
You may use a pseudonym but your email address (not visible) must be for an identifiable corporate domain, not a generic email service (mail.com, gmail.com, yahoo.com...).
The story must be fact (or at least your view of the facts)
You probably want to keep the company anonymous.
Entries must not be libelous, slanderous, confidential, or liable for any form of legal action
You must own copyright to the story
By submitting the story you waive copyright
Absolutely no names of real people are permitted
Personal attacks are not permitted, even on anonymous characters in the story (some people will recognise who it is). This is not about character nor attribution of blame.
There must be a story. "We had a project. It screwed up" will not be sufficient
The application of these rules to entries will be at the discretion of Two Hills Ltd. Decisions are final and no correspondence will be entered into.
By submitting an entry you are deemed to have agreed to these terms and conditions.
This book is essential reading for all decision makers (IT-literate or not) who are presented with an ITIL® proposal or asked to oversee an ITIL project, or find something called “ITIL” or “Service Management” in their budget. It tells you what the ITIL industry won’t. For everyone else involved in ITIL projects, this book will help you stay grounded and safe.
It's the end of the financial year, some money left in the pot. What to do?
Why, buy some PDAs of course, they'll be just what we need for our new ITIL Implementation Project.
20 iPAQs are purchased as well as licenses to run the "Mobile Portal" module of the Service Desk software.
However:
1. The "Mobile Portal" turned out to be bug-ridden, unfinished crap.
2. No money was left for consultancy to sort out the software issues and configure it for our use
3. No money was left for a decent server on which to run the "Mobile Portal"
4. The information security team banned the use of mobile devices as they couldn't effectively control internet access
A year passes, solutions are found for the above and testing starts.
The "Mobile Portal" works okay from a PC but won't work consistently via a wireless network.
When a good 3G signal is obtained it's fine but such conditions are rare in the rural areas we want the engineers to work.
Another year passes.
It's the end of the financial year, some money is left in the pot. What to do?
Why, those iPAQs are out of date, we need to buy the newer models which are bound to work better than the old ones ...
Submitted by choofie (not verified) on Thu, 2009-03-12 14:02.
This happened in the previous company I worked in, a big pharmaceutical industry heavyweight with an IT infrastructure team of at least 400 employees(excluding the contractors) worldwide. The year was 2001 and the company wanted to standardize the Incident, Change and Configuration Management processes of all its Service Desks worldwide. The project was named after a famous artist that brought us cubism and true to its name, the project looked like a cubism painting: you kinda know what it is but you know the parts were either distorted or all in the wrong place.
Anyway, it was "D" most important ITSM project for the organization. They had a big wig as the sponsor but unfortunately they got the in-house Remedy Administrator to pretty much run the "project"..the reason for the " " is because i never saw so much as a project plan. This was a global "project", impacting a few service desks around the world and they got the Remedy techie to run the "project"! As expected the techie designed the Remedy system as he saw fit..a typical case of putting the tool(cart) before understanding all the processes(horse)...i don't think there were any solicitation of requirements at all.. at least not from my part of the world...got us all(rather it was a force through political pressure) to provide the project data to import into the new system(mainly the customer's name, support staff name) Called for a training session and boy were we shock when the training session turned out to be a tool functionality demonstration. "You can do this on the tool or do that but the key points like:
- what are the CTIs(Category, Type, Item) we should choose for the various services we offered. Shouldn't the definitions be standardized as this is a global tool?
- how does the escalation notifications of the tickets work. Can we tune it to local needs?
- can we get some sort of reports/metrics required to see the health and performance of the SD
All these fell on deaf ears. Naturally using this tool would break the operations department's existing incident, change and configuration management processes thus the regional operations manager made a very brave decision to not go on the tool despite his boss strong disapproval. We later found out, we were not the only region that didn't go onto the tool. Some got on for 1 month and gave up...some chose to maintain two systems(rumours tells me the outsourced vendor did this) however they declared the project implemented but it keeps coming back to haunt us. The steering committee for this project got bigger(more political power i suppose), they put another project manager on top of the technie and gave him the technical supervisor role, the number of remedy programmers grew(fixing the initial bugs), the steering committee made roadshows to all the regions(sat down with us to understand why we didn't want to use the system but strangely enough none of them wrote anything down.They must have really good memory), in my region the project was given to any new hire with no clue about the nightmare behind this project....I left the company in 2006... it was still being implemented.. the amount of money they could have saved if they just understood one thing... process before tool.
I now see the same symptoms occurring in my present company. Tool before the process. lucky thing is the processes for incident and change is not so far off in all 3 regions so it kinda works...but configuration management..as the asset management processes differs in 3 regions, the story repeats...
This is the kind of horror story we are looking for, thank-you.
I think the mistake they made was not putting PEOPLE before process before tool. Most of the company hadn't bought in to the change, did not feel involved, felt they had no stake... If they had designed new company wide processes that addressed some or all of your questions and still dropped them on you in the same bombshell fashion it would have failed just as spectacularly no?
Submitted by choofie (not verified) on Sun, 2009-03-15 03:42.
Skeptic you are absolutely right. People before process before tool. Business change management and process engineering had been preaching this for a few decades. One that ties both IT and the business in this regard are ERP implementations. These days we don't hear as many failures of business implementation ERP but don't hear enough successes of IT departments/organizations implementing ITSM. The people in IT are one of the important ingredients behind many ERP success stories but it always baffles me why the IT profession(as a whole) with ERP implementations hindsight not have the foresight to see these two types projects share so many common implementation strategies.
I've banged this drum more than just about any other, to the point that I'm working on a book about people first
I drew this picture for a presentation I am giving at the itSMF conf here in May (come to lovely Wellington folks!) ppt
Some features of this diagram are deliberate.
People then process then technology, is the order we START. The People work will end after the process work after the technolgoy work (ignoring ongoing support and improvement)
People work defines and informs the process work, which then needs to be communicated and taught back to the People.
The Process defines the Technology requirements, but we restrain customisation, so the selected Technology will influence the Process.
I now know why the new format of PowerPoint is called pptx. Initially I thought the x means xml, but I guess this is a code for:
P -> People
P -> Process
T -> Technology
X -> This is where the miracle occurs!
Rob,
you're mixing two dimensions in one graph. As often, the result fits the reasoning but it has a flaw: the graph title is missing, so it may not apply to other reasonings...
The graph is applied for an organizational change approach: people, process, technology (PPT).
However, the graph does not apply for the organizational design approach: that's where PPT means process, people, technology.
In designing the (future) organization, you should first determine its identity: "what do you want to be, an automotive factory, a caterer, a farmer". And within each first-level answer there will be many more identity characteristics that will determine the activities and consequently the processes you'll need to do to get that identity.
Once you know what the organization needs to do, you can determine the required goals for competencies and skills in people. In case you have an existing organization, you may need to hire, fire or train people to reach these goals.
Finally, you'll have to give the people the equipment to perform their tasks at the required levels (limited by the amount of money you have for this).
So there's no single way of saying "PPT means .....", it quite depends upon what you want to do with it.
If you look at ITIL (as many do) there's no explanation of this, and the terms 'people' and 'process' are mixed with all kinds of others, like 'partners', 'products', 'documents', 'knowledge', 'applications', and so on. Little help there.....
You are right when you are starting from zilch in desiging your organization. On the other hand, if you already have an organization you should still start with people. If you don't you may easily design an organization for which your people are not (yet) mature enough.
So first think about what you want to be (this I would call G for goal), then
think about who you have on your team to go there (P), then
think about the processes you need (again a P) and last
think about technology to meet these processes (T).
and since you are also right about the characteristics inside these decisions, you start all over again. And if you have good people, they will enjoy the change and the challenge it brings.
Being a touchy feely kind of guy, despite my audit background, it always pains me to realise that some managers are never going to change and need to be shown the door because they don't internalise the need for change. A Twitter fed thought that has crossed my mind is should we be assessing the maturity of managers rather than organisations. As many wise people have said, staff leave managers, not the company.
Submitted by JamesFinister on Thu, 2009-03-12 20:28.
There is a theme that keeps coming up in my current reading - some people just shouldn't be doing the job they are given, especially if it it involves a major reinvention of their own values
Submitted by Ignacio (not verified) on Fri, 2009-02-20 10:50.
Well, first of all, sorry for my poor english, i hope the story makes up for it.
I work in a medium size company and our IT department is about 100 people. This story happened to a person who sits near to me so I just heard what was happening and tried not to laugh too much.
He is a 23 year man who has just finished his studies and whose pervious job was as a waiter in a fast food restaurant. It was his first day, and his responsible started to explain him what he will have to do. First he asked the newcomer if he knew what ITIL was, the answer was of course no. Then the responsible showed him a folder where he could find the information he would need (the five ITIL v3 books) and told him that the managers had decided to "implement ITIL" and what he had to do was to read the books and create a plan to implement ITIL in the whole IT department.
So the man started reading the books, googling for almost every word he read and the first thing he told his responsible was that they would need a consultant because it was a big project, the responsible asked the managers and a few days later he told the man that he had to create an "RFP" for a consultancy agency.
Of course the next thing the man did was looking in google what did RFP mean. when he seemed to understand, he started creating it and, when he had finished it, he showed it to the managers and they told him that he would get an answer in a few days.
The days became two months and the man spent all his time reading information about ITIL. After that time the managers told him a consultant was too expensive andthat he would have to create the whole ITIL plan.
Last week he showed his plan, it was a beatiful presentation, but the content of it was... well it seemed he had got random words from the ITIL books and put them together, there where no references to the service transition, there where ideas that only had been translated from some article and didn'd fit our company at all. Every time a person asked something the man turned almost white and said somthing that nobody could understand
The worst part is that the executive board seemed to like it and all indicates we will be following this plan, so in a few months I will have MANY new horror stories.
Hard to believe and yet easy to believe. I've met IT "experts" whose previous jobs included real estate salesman and photocopier serviceman. Come to think of it, I went straight from wine waiter to 4GL consultant/trainer
Submitted by JamesFinister on Fri, 2009-02-20 20:21.
Really sad thing is I think we have LOTS to learn from the fast food industry where process is king and delivery of a commodity service meets the need of an otherwise diverse customer base, which is it self "trained" to fit in with the process. I've said it before and I'll say it again, IT will never learn how to do IT well until it looks at how other professions do things well.
"What do they know of England who only England know"
Submitted by ignacio (not verified) on Mon, 2009-02-23 07:54.
The problem isn't the fast food job, I also worked in a fast food restauran, in human resources and even as fencing teacher before ending in an IT department. And all this experience has helped me a LOT.
The problem is giving a person who doesn't know what ITIL is the five ITIL v3 books and thinking that will make him and expert.
Submitted by Horrorshow (not verified) on Thu, 2009-02-19 14:14.
The reason I put that in the rules is in case I want to use the material in a book or paper in future, e.g include the stories in the second edition of the book.
Every time you comment on this blog you waive copyright unless you specify otherwise, it's in the Ts & Cs.
It is also only making explicit what is implicit: by posting something on a website it is fairly assumed you are placing it in the public domain unless you specify otherwise, as I do by explicitly claiming copyright and reserving all rights on every page.
The Worst of the IT Skeptic is in final preparation: it is a compilation of the blog. it so happens I chose not to include comments but I could have. It hurt not to. The comments are of such a high quality on this blog that I am thinking of a follow-up book of edited threads.
If you think your horror story is worth more than $34.95 + p&p then by all means hang on to it :)
Submitted by Mark (not verified) on Wed, 2009-02-18 19:28.
A large organisation implemented a total backup UPS system. Therefore they were covered in the event of a national grid type power failure (or so they thought). Well it happened, the grid went down and made the news, but their UPS never kicked in. Continuity just didn't happen. Afterwards it was found out that the UPS had not been tested to see if it worked. This was a services company and the knock on effect was high.
I don't want to bash ITIL as they did put in a UPS i.e. addressing continunity, though part of any change and continunity plan is the testing, but it is a project horror story as they never tested if it worked. Caused havoc for a while.
Submitted by JamesFinister on Wed, 2009-02-18 13:19.
First of all the rules of the competition mean I can't talk about most of my horror stories.
But how about a government agency on the bleeding edge of new technologies whose CIO says" I want to hear about totally innovative ITSM solutions that will give us a clear USP in the market place" and then refuses to accept any idea unless we can point to at least three comparable organisations (Think national security for other nations - or a long jail sentence for whichever poor junior consultant we sent out to do the research) that have already been using the ideas for at least five years.
I got a phone call from a person who was working for a large international company. This person was assigned to set up a service desk and wanted me to review his plan. We agreed that I will spend one day reviewing and commenting the plan and he sent it to me.
The plan was perfectly good project plan with activities and milestones but it was really a plan to select and install software. My customer thought that he was setting up a Service Desk by installing the software and that this would happen in nine weeks. I told him that he had overlooked all the hard parts and that it would most likely take at least nine months. He did not like my message. Customer relationship ended but I got my one day fee.
Year later a new person called from the same company, he had the same assignment and I suspect he had the same approach and schedule too. I described my previous assignment with the project and that was it. Unfortunately I do not know how it ended.
Made in New Zealand 
Comments
Toys
It's the end of the financial year, some money left in the pot. What to do?
Why, buy some PDAs of course, they'll be just what we need for our new ITIL Implementation Project.
20 iPAQs are purchased as well as licenses to run the "Mobile Portal" module of the Service Desk software.
However:
1. The "Mobile Portal" turned out to be bug-ridden, unfinished crap.
2. No money was left for consultancy to sort out the software issues and configure it for our use
3. No money was left for a decent server on which to run the "Mobile Portal"
4. The information security team banned the use of mobile devices as they couldn't effectively control internet access
A year passes, solutions are found for the above and testing starts.
The "Mobile Portal" works okay from a PC but won't work consistently via a wireless network.
When a good 3G signal is obtained it's fine but such conditions are rare in the rural areas we want the engineers to work.
Another year passes.
It's the end of the financial year, some money is left in the pot. What to do?
Why, those iPAQs are out of date, we need to buy the newer models which are bound to work better than the old ones ...
Service Support Implementation
This happened in the previous company I worked in, a big pharmaceutical industry heavyweight with an IT infrastructure team of at least 400 employees(excluding the contractors) worldwide. The year was 2001 and the company wanted to standardize the Incident, Change and Configuration Management processes of all its Service Desks worldwide. The project was named after a famous artist that brought us cubism and true to its name, the project looked like a cubism painting: you kinda know what it is but you know the parts were either distorted or all in the wrong place.
Anyway, it was "D" most important ITSM project for the organization. They had a big wig as the sponsor but unfortunately they got the in-house Remedy Administrator to pretty much run the "project"..the reason for the " " is because i never saw so much as a project plan. This was a global "project", impacting a few service desks around the world and they got the Remedy techie to run the "project"! As expected the techie designed the Remedy system as he saw fit..a typical case of putting the tool(cart) before understanding all the processes(horse)...i don't think there were any solicitation of requirements at all.. at least not from my part of the world...got us all(rather it was a force through political pressure) to provide the project data to import into the new system(mainly the customer's name, support staff name) Called for a training session and boy were we shock when the training session turned out to be a tool functionality demonstration. "You can do this on the tool or do that but the key points like:
- what are the CTIs(Category, Type, Item) we should choose for the various services we offered. Shouldn't the definitions be standardized as this is a global tool?
- how does the escalation notifications of the tickets work. Can we tune it to local needs?
- can we get some sort of reports/metrics required to see the health and performance of the SD
All these fell on deaf ears. Naturally using this tool would break the operations department's existing incident, change and configuration management processes thus the regional operations manager made a very brave decision to not go on the tool despite his boss strong disapproval. We later found out, we were not the only region that didn't go onto the tool. Some got on for 1 month and gave up...some chose to maintain two systems(rumours tells me the outsourced vendor did this) however they declared the project implemented but it keeps coming back to haunt us. The steering committee for this project got bigger(more political power i suppose), they put another project manager on top of the technie and gave him the technical supervisor role, the number of remedy programmers grew(fixing the initial bugs), the steering committee made roadshows to all the regions(sat down with us to understand why we didn't want to use the system but strangely enough none of them wrote anything down.They must have really good memory), in my region the project was given to any new hire with no clue about the nightmare behind this project....I left the company in 2006... it was still being implemented.. the amount of money they could have saved if they just understood one thing... process before tool.
I now see the same symptoms occurring in my present company. Tool before the process. lucky thing is the processes for incident and change is not so far off in all 3 regions so it kinda works...but configuration management..as the asset management processes differs in 3 regions, the story repeats...
thank-you
This is the kind of horror story we are looking for, thank-you.
I think the mistake they made was not putting PEOPLE before process before tool. Most of the company hadn't bought in to the change, did not feel involved, felt they had no stake... If they had designed new company wide processes that addressed some or all of your questions and still dropped them on you in the same bombshell fashion it would have failed just as spectacularly no?
People before process before technology
Skeptic you are absolutely right. People before process before tool. Business change management and process engineering had been preaching this for a few decades. One that ties both IT and the business in this regard are ERP implementations. These days we don't hear as many failures of business implementation ERP but don't hear enough successes of IT departments/organizations implementing ITSM. The people in IT are one of the important ingredients behind many ERP success stories but it always baffles me why the IT profession(as a whole) with ERP implementations hindsight not have the foresight to see these two types projects share so many common implementation strategies.
PPT
I've banged this drum more than just about any other, to the point that I'm working on a book about people first
I drew this picture for a presentation I am giving at the itSMF conf here in May (come to lovely Wellington folks!)
ppt
Some features of this diagram are deliberate.
People then process then technology, is the order we START. The People work will end after the process work after the technolgoy work (ignoring ongoing support and improvement)
People work defines and informs the process work, which then needs to be communicated and taught back to the People.
The Process defines the Technology requirements, but we restrain customisation, so the selected Technology will influence the Process.
pptx
Hi Rob,
I now know why the new format of PowerPoint is called pptx. Initially I thought the x means xml, but I guess this is a code for:
P -> People
P -> Process
T -> Technology
X -> This is where the miracle occurs!
;-)
Marc
two dimensions, disagreee for one
Rob,
you're mixing two dimensions in one graph. As often, the result fits the reasoning but it has a flaw: the graph title is missing, so it may not apply to other reasonings...
The graph is applied for an organizational change approach: people, process, technology (PPT).
However, the graph does not apply for the organizational design approach: that's where PPT means process, people, technology.
In designing the (future) organization, you should first determine its identity: "what do you want to be, an automotive factory, a caterer, a farmer". And within each first-level answer there will be many more identity characteristics that will determine the activities and consequently the processes you'll need to do to get that identity.
Once you know what the organization needs to do, you can determine the required goals for competencies and skills in people. In case you have an existing organization, you may need to hire, fire or train people to reach these goals.
Finally, you'll have to give the people the equipment to perform their tasks at the required levels (limited by the amount of money you have for this).
So there's no single way of saying "PPT means .....", it quite depends upon what you want to do with it.
If you look at ITIL (as many do) there's no explanation of this, and the terms 'people' and 'process' are mixed with all kinds of others, like 'partners', 'products', 'documents', 'knowledge', 'applications', and so on. Little help there.....
Who designs organizations (from scratch)?
Hi Jan,
You are right when you are starting from zilch in desiging your organization. On the other hand, if you already have an organization you should still start with people. If you don't you may easily design an organization for which your people are not (yet) mature enough.
So first think about what you want to be (this I would call G for goal), then
think about who you have on your team to go there (P), then
think about the processes you need (again a P) and last
think about technology to meet these processes (T).
and since you are also right about the characteristics inside these decisions, you start all over again. And if you have good people, they will enjoy the change and the challenge it brings.
Marc
that was already agreed
Marc - we already agreed on the preferred order for organizational change. People first. But that was not the point.
Hire, fire, CMMI
Being a touchy feely kind of guy, despite my audit background, it always pains me to realise that some managers are never going to change and need to be shown the door because they don't internalise the need for change. A Twitter fed thought that has crossed my mind is should we be assessing the maturity of managers rather than organisations. As many wise people have said, staff leave managers, not the company.
Wrong kind of people
There is a theme that keeps coming up in my current reading - some people just shouldn't be doing the job they are given, especially if it it involves a major reinvention of their own values
ITIL is not that big
Well, first of all, sorry for my poor english, i hope the story makes up for it.
I work in a medium size company and our IT department is about 100 people. This story happened to a person who sits near to me so I just heard what was happening and tried not to laugh too much.
He is a 23 year man who has just finished his studies and whose pervious job was as a waiter in a fast food restaurant. It was his first day, and his responsible started to explain him what he will have to do. First he asked the newcomer if he knew what ITIL was, the answer was of course no. Then the responsible showed him a folder where he could find the information he would need (the five ITIL v3 books) and told him that the managers had decided to "implement ITIL" and what he had to do was to read the books and create a plan to implement ITIL in the whole IT department.
So the man started reading the books, googling for almost every word he read and the first thing he told his responsible was that they would need a consultant because it was a big project, the responsible asked the managers and a few days later he told the man that he had to create an "RFP" for a consultancy agency.
Of course the next thing the man did was looking in google what did RFP mean. when he seemed to understand, he started creating it and, when he had finished it, he showed it to the managers and they told him that he would get an answer in a few days.
The days became two months and the man spent all his time reading information about ITIL. After that time the managers told him a consultant was too expensive andthat he would have to create the whole ITIL plan.
Last week he showed his plan, it was a beatiful presentation, but the content of it was... well it seemed he had got random words from the ITIL books and put them together, there where no references to the service transition, there where ideas that only had been translated from some article and didn'd fit our company at all. Every time a person asked something the man turned almost white and said somthing that nobody could understand
The worst part is that the executive board seemed to like it and all indicates we will be following this plan, so in a few months I will have MANY new horror stories.
experts
Hard to believe and yet easy to believe. I've met IT "experts" whose previous jobs included real estate salesman and photocopier serviceman. Come to think of it, I went straight from wine waiter to 4GL consultant/trainer
Fast food
Really sad thing is I think we have LOTS to learn from the fast food industry where process is king and delivery of a commodity service meets the need of an otherwise diverse customer base, which is it self "trained" to fit in with the process. I've said it before and I'll say it again, IT will never learn how to do IT well until it looks at how other professions do things well.
"What do they know of England who only England know"
Fast food
The problem isn't the fast food job, I also worked in a fast food restauran, in human resources and even as fencing teacher before ending in an IT department. And all this experience has helped me a LOT.
The problem is giving a person who doesn't know what ITIL is the five ITIL v3 books and thinking that will make him and expert.
Copyright
There was me, writing away, I found I'd got a nice little list of horror stories and I was enjoying getting them down, as a diversion.
Then I spotted your clause about giving up copyright. I'd love the book, but that seems a very high price to pay...
you waive copyright
The reason I put that in the rules is in case I want to use the material in a book or paper in future, e.g include the stories in the second edition of the book.
Every time you comment on this blog you waive copyright unless you specify otherwise, it's in the Ts & Cs.
It is also only making explicit what is implicit: by posting something on a website it is fairly assumed you are placing it in the public domain unless you specify otherwise, as I do by explicitly claiming copyright and reserving all rights on every page.
The Worst of the IT Skeptic is in final preparation: it is a compilation of the blog. it so happens I chose not to include comments but I could have. It hurt not to. The comments are of such a high quality on this blog that I am thinking of a follow-up book of edited threads.
If you think your horror story is worth more than $34.95 + p&p then by all means hang on to it :)
One such story
Hi,
A large organisation implemented a total backup UPS system. Therefore they were covered in the event of a national grid type power failure (or so they thought). Well it happened, the grid went down and made the news, but their UPS never kicked in. Continuity just didn't happen. Afterwards it was found out that the UPS had not been tested to see if it worked. This was a services company and the knock on effect was high.
I don't want to bash ITIL as they did put in a UPS i.e. addressing continunity, though part of any change and continunity plan is the testing, but it is a project horror story as they never tested if it worked. Caused havoc for a while.
Innovation
First of all the rules of the competition mean I can't talk about most of my horror stories.
But how about a government agency on the bleeding edge of new technologies whose CIO says" I want to hear about totally innovative ITSM solutions that will give us a clear USP in the market place" and then refuses to accept any idea unless we can point to at least three comparable organisations (Think national security for other nations - or a long jail sentence for whichever poor junior consultant we sent out to do the research) that have already been using the ideas for at least five years.
Setting up a Service Desk
I got a phone call from a person who was working for a large international company. This person was assigned to set up a service desk and wanted me to review his plan. We agreed that I will spend one day reviewing and commenting the plan and he sent it to me.
The plan was perfectly good project plan with activities and milestones but it was really a plan to select and install software. My customer thought that he was setting up a Service Desk by installing the software and that this would happen in nine weeks. I told him that he had overlooked all the hard parts and that it would most likely take at least nine months. He did not like my message. Customer relationship ended but I got my one day fee.
Year later a new person called from the same company, he had the same assignment and I suspect he had the same approach and schedule too. I described my previous assignment with the project and that was it. Unfortunately I do not know how it ended.
Aale Roos