IT project management-System Acceptance

IT project management-System Acceptance

The system acceptance has been promoted since the end of June and will not end until August.

As we all know, the acceptance of the system marks the approval of Party A and the collection of project funds. Generally, the system is officially launched for Party A and the project is successful for Party B. Generally, the software contract is based on the ratio of or, that is, the amount paid after the system acceptance will account for more than half of the total contract amount. Therefore, it is understandable that Party A is cautious in System Acceptance. At this stage, you can see frequent system changes and careful requirements on the details. At this stage, the project team members were exhausted and lost their passion in the early stage of the project. We hope to carry out System Acceptance earlier, return to the company, and make new status adjustments. Conflicts of different attitudes and interests may cause sharp conflicts between the two parties. If Party A may accuse Party B of being irresponsible, Party B may accuse Party A of being difficult.

In fact, we can carefully analyze the mentality of Party A and Party B on system acceptance.

For Party A, the implementation of the project is an arduous process, and Party A also has a performance appraisal mechanism. Therefore, the system acceptance of Party A's project manager is also a relief. In this regard, the interests of both parties are the same. However, Party A may consider whether the implementer can provide requirements change and system development support after system acceptance and payment. If not, how will the superiors take responsibility. This may be the reason why all requirements must be addressed before system acceptance.

In addition, for Party B, in the initial stage of the project, due to the pressure of market competition, it is often difficult for sales and PM to completely eliminate the promise of marketing transition. In this case, if the acceptance is based on the contract and technical agreement, I think there may be very few development projects that meet the original requirements of the contract. In addition, the initial technical solution of the project generally only talks about the service content and implementation objectives, which is very general. The results are prone to business needs explosion during the implementation process, which is hard for software vendors to cope.

After understanding the mentality and dilemmas of both parties, how can we effectively promote system acceptance?

Select an appropriate time for acceptance. After a business application is recognized by some users, it is the best time for acceptance. Once a business of the project enters the usable state, the project manager should take the initiative to discuss acceptance conditions, provide the corresponding acceptance plan, plan and acceptance report.

As the problem is on the stage, it will inevitably enter a deadlocked stage. At this stage, Party A will conduct relevant tests on the demand and test cases, and put forward its own requirements on the existing problems. Of course, we must first respect and face up to the problems in the system, classify the problems and sort their priorities. The classification is a local problem or a global problem, it is a problem that is easy to solve or difficult to implement. The priority is based on Party A's attention to the problem. Of course, first of all, we need to solve the global problems with higher priority. This will reflect the importance that Party B attaches to the problem. The second is to solve the minor problems that are relatively easy. This will effectively reduce the bug rate of the system and let Party A see the progress and results of the work.

In addition, Jiang sales manager plays an irreplaceable role here, because during the acceptance process, the opposition of positions and the imbalance of mentality are unavoidable, technical Personnel-based project managers often lack skills in communication, which can easily lead to greater conflicts. In addition, due to the strong attitude of Party A's project managers, it is generally difficult for Party B's project to reject some new requirements and demand changes from Party A. Therefore, it is necessary to add a link buffer during project acceptance.

Of course, there are still some problems that may not be solved by the project itself. For example, the C/S module in this project uses the company's previous product architecture, and the people who maintain this product have basically left the company, re-development of the C/S module may be longer than the development cycle of this project. This is obviously unrealistic and beyond the controllable scope of the project manager. Of course, it is not what the project manager can promise. This requires the technical director and company leaders to make corresponding PR and commitments.

After more than one month of bug fixing, after sales PR, high-level exchanges between company leaders, and the commitment of the Technical Director, both parties reached an agreement regarding the project acceptance:

L acceptance of each subsystem is started separately.

L for new business requirements and some bugs, technicians will be stationed for on-site development.

L promises to solve the functions and objectives that cannot be achieved in this project in the next phase.

Finally, a deliverable list is submitted:

Xxxsystem acceptance report .doc

Xxxsystem acceptance .doc

System Architecture

Xxxsystem 2.16.xls

System Requirements

Xxxsystem sssubsystem Requirement Description. xls

Xxxsystem yysubsystem Requirement Description. Doc

Xxxsystem zzzi System Requirement Description. Doc

Xxxsystem Data Warehouse Requirement Description .doc

System Design

Xxxsystem data warehouse system design description. Doc

Xxxsystem sssubsystem design description. Doc

Xxxsystem yysubsystem design description. Doc

Xxxsystem zzzi system design description. Doc

Data Dictionary

Xxxsystem sssubsystem data dictionary .doc

Xxxsystem: yysubsystem data dictionary. Doc

Xxxsystem zzsubsystem data dictionary .xls

System Test

Xxxsystem yysubsystem test report .doc

Xxxsystem yysubsystem test example .doc

Xxxsystem yysubsystem test plan .doc

Xxxsystem sssubsystem test report .doc

Xxxsystem yysubsystem test example .doc

Xxxsystem zzsubsystem test plan .doc

User Manual

Xxxsystem sssubsystem user manual. Doc

Xxxsystem yysubsystem user manual. Doc

Xxxsystem zzzi system user manual. Doc

Xxxsystem maintenance manual .doc

System Installation Package

System source code

Of course, there are also some internal project management documents, such as the project progress report and adjustment, the minutes of previous meetings, the overall project budget, and the project budget expenditure, which are finally submitted to the company.

The project began in March and ended in March of the following year. The field developers kept at least 10 people, nearly 20 people at the highest, and about 10 people from the core team, there are also a dozen members in the peripheral Development and Support Team. The total amount of software and hardware in this project is more than 12 million yuan, and the amount of pure software is more than 4 million yuan. This is the biggest project of the company since its establishment. This is my challenge and exercise for myself.

Thanks to all stakeholders, the leaders of the company, and the team members for the successful acceptance of the system. Two months later, the company received the project acceptance fee.

 

This article is from the book "IT project management ".

Book details: http://blog.csdn.net/broadview/article/details/6750539