Why the projects fails
The last week I was fired from my job; this is my essay about what makes fails a system delivering. I will not put names, but I will put situations. I won't say where I was working except I will say it was a School.
The situation:
I start to work about two months after the system was started, a co-worker tell me about the details of the starting implementation.
When I started to work I checked the code has about 20,000 lines of code, something really big. As I wasn't used to the system I though almost all was implemented and I only had to fix certain parts of the system.
The system in fact was very small and all the code was "garbage" code written by former developers and they don't clean the code (something later I learn why). Also there was a lot of implementation of certain parts, for example get the internal ID for the semester course, this was a small query in a function of about 10 lines of code, almost on every script.
I was in charge to develop the print of notes of the students, I finish fast my assign and I though this was really easy. I develop four similar scripts which have the same base for all the sections.
After two weeks I finish the scripts started the argues.
First I had some problems with two sections because there was certain things nobody told me, and also nobody told to the IT department; so we have to write certain parts to fulfill the needs. Nothing "bad". But after each month the users want to argue another "certain" parts which some of them were not of the knowledge of the department and others were missed to tell me (and the boss pretend to say me the same: "You have to ask").
After a lot of problems I was in charge with a section where the principal ask me three weeks before a "very important" module for his section, print the certificates of the university. The module was really easy but I found two problems:
1) There was a lot of information lack, one of them the sex of the students, another things the official ID assigned by the official education secretary of the state.
I give to the principal all the student information which was missing to fulfill two weeks ago. He never see the information and at the end he pretend to say he was to make this information miss because I never ask this to he.
2) Suddenly one day they ask me to do in ten minutes a "closing course cycle", this wasn't done for the section I was in charge and the person who assign us the modules thought this was very easy. Only was done in one day and as that afternoon I don't come back to work they fall into panic and have to do this almost by hand to 600 students.
There was a lot of things which happens, they really are amateur to do IT. But let me point some of the main drawbacks both in IT and in Project Management:
1) They never ask to the users what they want or see what they were used to do (they work with a system made in VB and Access).
2) They never show to the users how to work with the new system.
3) The users was used to ask and receive modules after the coding was done; without QA control or even proper testing. The testing and bug discovering was done by the users (the most expensive model).
4) From the last point the users though programming a module was so easy as touch the proper button. So we were only as secretary writing a letter or something similar. So they never though some things have to almost rewrite certain parts of the system to fulfill their needs.
5) As there was never a control of versions our internal boss always was making changes to the DB without asking or even notice us the changes. We see those changes when the user discovered lot of bugs.
6) First there was a person which his only job was provide us feedback from the users. After the boss though it was a good idea to assign us each of us (the programmers) a user or a department. When I start to see the users I see the point 1) was fulfilled without problems, and also another thing, if the user ask four changes, one was discarded as "all is working fine", one change was done and the other two things was lost.
Also with this change the programmers have to double the work and the other person was making a long long relaxing period.
So what was the bes project handling?
Simple:
1) Mimic all the system functions in a closed way (the users will use their usual system)
2) When all the mimic was done and all the function (and a period of testing was done), the system will go online and all the data will be stored into the system
3) Teach the users about the new features and how they have to work now (this is the most conflictive way)
4) Show the users the changes are good through examples with them.
5) The new features has to be done in a proper cycle of development. The bugs has to be top priority, but can't be considered a bug something not implemented (because the users don't tell us).
So easy =).
The situation:
I start to work about two months after the system was started, a co-worker tell me about the details of the starting implementation.
When I started to work I checked the code has about 20,000 lines of code, something really big. As I wasn't used to the system I though almost all was implemented and I only had to fix certain parts of the system.
The system in fact was very small and all the code was "garbage" code written by former developers and they don't clean the code (something later I learn why). Also there was a lot of implementation of certain parts, for example get the internal ID for the semester course, this was a small query in a function of about 10 lines of code, almost on every script.
I was in charge to develop the print of notes of the students, I finish fast my assign and I though this was really easy. I develop four similar scripts which have the same base for all the sections.
After two weeks I finish the scripts started the argues.
First I had some problems with two sections because there was certain things nobody told me, and also nobody told to the IT department; so we have to write certain parts to fulfill the needs. Nothing "bad". But after each month the users want to argue another "certain" parts which some of them were not of the knowledge of the department and others were missed to tell me (and the boss pretend to say me the same: "You have to ask").
After a lot of problems I was in charge with a section where the principal ask me three weeks before a "very important" module for his section, print the certificates of the university. The module was really easy but I found two problems:
1) There was a lot of information lack, one of them the sex of the students, another things the official ID assigned by the official education secretary of the state.
I give to the principal all the student information which was missing to fulfill two weeks ago. He never see the information and at the end he pretend to say he was to make this information miss because I never ask this to he.
2) Suddenly one day they ask me to do in ten minutes a "closing course cycle", this wasn't done for the section I was in charge and the person who assign us the modules thought this was very easy. Only was done in one day and as that afternoon I don't come back to work they fall into panic and have to do this almost by hand to 600 students.
There was a lot of things which happens, they really are amateur to do IT. But let me point some of the main drawbacks both in IT and in Project Management:
1) They never ask to the users what they want or see what they were used to do (they work with a system made in VB and Access).
2) They never show to the users how to work with the new system.
3) The users was used to ask and receive modules after the coding was done; without QA control or even proper testing. The testing and bug discovering was done by the users (the most expensive model).
4) From the last point the users though programming a module was so easy as touch the proper button. So we were only as secretary writing a letter or something similar. So they never though some things have to almost rewrite certain parts of the system to fulfill their needs.
5) As there was never a control of versions our internal boss always was making changes to the DB without asking or even notice us the changes. We see those changes when the user discovered lot of bugs.
6) First there was a person which his only job was provide us feedback from the users. After the boss though it was a good idea to assign us each of us (the programmers) a user or a department. When I start to see the users I see the point 1) was fulfilled without problems, and also another thing, if the user ask four changes, one was discarded as "all is working fine", one change was done and the other two things was lost.
Also with this change the programmers have to double the work and the other person was making a long long relaxing period.
So what was the bes project handling?
Simple:
1) Mimic all the system functions in a closed way (the users will use their usual system)
2) When all the mimic was done and all the function (and a period of testing was done), the system will go online and all the data will be stored into the system
3) Teach the users about the new features and how they have to work now (this is the most conflictive way)
4) Show the users the changes are good through examples with them.
5) The new features has to be done in a proper cycle of development. The bugs has to be top priority, but can't be considered a bug something not implemented (because the users don't tell us).
So easy =).
