| Software project failure is often devastating to an | | | | -Carefully connect the goal of your project to larger |
| organization. Schedule slips, buggy releases and | | | | goals in the organization. |
| missing features can mean the end of the project or | | | | -Show how achieving your project goal will further |
| even financial ruin for a company. Oddly, there is | | | | the goals of your own area. |
| disagreement over what it means for a project to | | | | -Develop the same connection between the project |
| fail. | | | | goal and the goals of those managers from whom |
| A project can be considered a failure if;o It deviates | | | | you need support. |
| too far from original specificationso It doesn't meet | | | | Poor Interpersonal Skills |
| key user requirementso It is late or over budget | | | | -Respect, listen, communicate, and be honest |
| The main IT project failure criteria;o Missed deadlines | | | | User Involvement |
| (Time)o Exceeded budget (Cost)o Inability to project | | | | -Users need to be involved from the start, and |
| requirements (Scope) | | | | continuously throughout the development. |
| The main IT project success criteria;o Meeting | | | | -Make necessary arrangements with the user |
| milestones and deadlineso Meeting the budgeto | | | | managers so that users can actively participate |
| Meeting the project requirements | | | | project. |
| Statistics over Projects Failure Rate | | | | -Train users about the technology |
| Based on the surveys performed in North America, | | | | -Help user to have them understand what they really |
| statistics presented by the organization called IT | | | | want |
| Cortex;o An IT project is more likely to be | | | | Unrealistic Time Scales |
| unsuccessful than successfulo About 1 out of 5 IT | | | | -Don't under estimate or over estimate the project |
| projects is likely to bring full satisfactiono The larger | | | | timeline |
| the project the more likely the failureo 70% of IT | | | | -Consider the volume of work that needs to be done |
| projects "fail" | | | | to ensure delivery |
| The best documented IT project failures are the | | | | -Review all project plans to see if they are realistic |
| ones involving public money. The most recent | | | | -Challenge the participants to express any worries |
| example is the Virtual Case File project for the United | | | | they may have |
| States Federal Bureau of Investigation (FBI). The FBI | | | | No Change Control System |
| had admitted the Virtual Case File Technology had | | | | -Use phased approach to build systems, so that |
| failed to meet the bureau's requirements and five | | | | change has less chance to affect development. |
| years of development and $US 170 million in cost had | | | | -Evaluate the effects of any changed requirements |
| been lost (2005). | | | | on the timescale, cost and risk of project. |
| Top Reasons of Project Failure | | | | -If the change is inevitable, follow change control |
| Lack of Communicationo Poor Communicationo Poor | | | | process. |
| interpersonal skillso Lack of user involvement | | | | Poor Testing |
| Lack of Planningo Setting an overly ambitious project | | | | -The users must run acceptance tests to see if the |
| scopeo Lack of project methodologyo Poor user | | | | system meets the business requirements |
| input and requirements gatheringo Unrealistic time | | | | -Check the system methodically |
| scales | | | | -Plan and design tests. |
| No quality controlo Scope creepo No change control | | | | -Have sufficient time to achieve the testing |
| systemo Poor testing | | | | objectives |
| Poor managemento Lack of support from senior | | | | -Train users who do not know what the purpose of |
| managemento Mismanagement of progress | | | | testing is |
| Solutions | | | | Summary |
| Poor Communication | | | | How the project can be successful: |
| -Make sure to keep key stakeholders up-to-date as | | | | Technical Lead: |
| expectations get changed. | | | | Don't use a Technical Lead that has never built a |
| -If people are not kept informed as to what is going | | | | similar system. The person in the role of project |
| on, they will be surprised when changes occur. | | | | Technical Lead must be experienced. He/she should |
| -Make sure to send all required information to the | | | | have completed other successful similar projects. The |
| stakeholders via project status reports. | | | | role of technical lead is like that of a skilled heart |
| -If you send updates to stakeholders and they | | | | surgeon. You would not expect a family doctor to |
| continually follow-up with you for more information, it | | | | perform brain surgery or administer anesthesia. It is |
| is a sign that your communications are not targeted | | | | critical for the person in charge of the technical |
| correctly. | | | | aspects of the project to have experience with the |
| -Explain clearly what team members are expected to | | | | type of system being built. |
| do | | | | Developer: |
| -Communicate clearly the work that is not necessary | | | | Don't hire too many developers to make the coding |
| Project Scope | | | | go. More is not always better. This is especially true in |
| -Understand the difference between what you want | | | | the case of development teams. |
| to accomplish and what you're actually able to | | | | Testing: |
| accomplish. | | | | Don't skip the testing phase because the project is |
| -Do NOT commit when goals exceed your ability to | | | | way behind schedule. The time spent to thoroughly |
| deliver timely results. | | | | test any system before placing it into production can |
| Poor User Input and Requirements | | | | save much more time in the long run. |
| -Don't give users something they didn't ask for | | | | Scope Change: |
| -Write down user requirements formally and have | | | | Don't change the system to support critical new |
| approval from user | | | | requirements discovered during final development. |
| -Establish clear user requirements | | | | Enforce hard and fast rules about what changes are |
| -Develop a formal set of project specs | | | | acceptable and when changes can be made. |
| -Don't forget that systems are built to support the | | | | Methodology: |
| end-user, not the developers. | | | | Don't cut corners, methodologically. In the long run, |
| -Requirements need to be worked out on both | | | | this results in system failure or an inadequate system |
| sides:o Users - who know the business processes | | | | that doesn't meet the users' needs. |
| best - need to clearly express their requirements and | | | | Project managers must focus on three dimensions of |
| provide feedback on each project deliverable.o | | | | project success. Project success means completing all |
| Developers - who know what technology can be | | | | project deliverables on time, within budget, and to a |
| used to put those business processes into place - | | | | level of quality that is acceptable to sponsors and |
| need to ask the right questions and not make any | | | | stakeholders. The project manager must keep the |
| assumptions on what they think the users mean. | | | | team's attention focused on achieving these broad |
| Senior Management Support | | | | goals. |