We must learn to learn from the project failure, as long as we can have a big mind to face it, then make mistakes are not a bad thing. In fact, the factors affecting our project failure are mainly divided into
Technical failure: 1. The temptation of leading technology 2, imperfect technical design 3. Provide technical solutions for non-technical issues 4, depending on the package to meet the demand 5, do not take advantage of tools 6 during the development of life cycle, Technology-oriented development
Artificial failure: 1. Lack of administrative support 2, lack of leadership 3, no professional project team 4, functional project team 5, managing third party failure 6, lack of project elite 7, missing project ownership 8, related personnel Conflict 9, refuse to change 10, hostile organizational culture 11, experience insufficient project manager 12, lack of business reasons 13, unclear or ambiguous business priority 14, lack of user training 15, relevant personnel motivation is inconsistent
Process failure: 1. Lack of project management method system 2, lack of system development method system 3, lack of income management method system 4, lack of quality management method system 5, failure to determine and transfer project risk 6, fail management requirements 7, too long Project timetable 8, test lack of 9, computerized "explosion" method
Subsing the lesson from the project failure is an important part of the continuous improvement process. Now there are some main lessons lessons 1, manage users expect. That is, our project staff should understand what you need to deliver from the beginning and what you want to deliver. To determine the user's needs and establish as clear commercial ownership in the project. Even in the best case, the information previously received is limited. Normally, it is difficult to determine suitable users with feedback information. In the beginning of the project, you need to determine the main user needs and provide time for the primary user so that they determine the needs of the department, and they also have the responsibility to provide and verify information and put the corresponding resources. 2. Business requirements and user needs must be considered in the project specifications. First, we must clarify two concepts. First, the project is due to determinable and measurable business requirements. The clear goal determined in the initial period of the software project will gradually become blurred as the project progresses, which is the characteristics of the project with too long delivery. Therefore, before the project begins, it is necessary to determine the end user to fully consider their needs during the design and development of the software project, while the user is responsible and needs to take corresponding actions to help the project have succeeded. This is very important. Users need to form a crucial link in the analysis and design phase of the project. After the demand is determined, the baseline is determined for these needs, and they are introduced into the configuration management system, while the change control is managed. If these requirements have changed or add new demands, the project needs to be influenced and the project plan is corrected. And some organizations that use incremental and iterative methods development software, they also need to freeze the needs of each software version, and establish a corresponding mechanism (version control in the determined time points and function points, detail, for example, project Version control can specifically build a folder for version control, then sear with the update file of this folder every day, and make the full path to the full path to update the full path to the full path), so that The development baseline adds a new need for higher priority requirements (determined priority in user demand feedback). Second, the project specifications must focus on business needs rather than technical solutions. Therefore, even if there is a clear solution from technology, it is still necessary to focus on the business-related aspects when performing an item review. 3. Measure and evaluate the scale and complexity of the project before approved resources (pay attention to implementation). The development of technical strength has brought a unfortunate consequence to let us believe that many of the past it impossible now can not only be achieved, but it can be realized easily. Sometimes this idea is usually exaggerated in the early stages of the project to exaggerate the potential benefits of the project, too large project scope definitions and excessive optimism is quite dangerous and is not detailed enough. Therefore, we need to be clearly determined: a, the proposed project schedule is actively feasible; b, the commercial case of the project is feasible; C, the solution is technical in technology; the size and complexity of the software project is the success of the project A decisive factor. 4. The introduction of software projects will inevitably bring a wide variety of changes. The new technologies have a lot of influence on the role and responsibility of new technicians, and it is easy to lead to unclear procedures and responsibilities. Therefore, in the project plan, it is important to ensure that employees know how to use and maintain systems is critical. There is no reasonable training is the whole potential income that will never achieve software investment. More importantly, lack of training may bring business risks and operational risks, which may eventually threaten the long-term availability of the project. 5. Clearly visible project management structure is critical to the project. There must be clear roles, responsibilities, and obligations in the management structure.
