Keywords: IT scope management change control
I. Introduction
Scope management is a special vocabulary in project management. Its main task is to define that the project contains all the work that needs to be completed, and guide other project management work to ensure the smooth completion of all the processes of the project.
Generally speaking, when the scope of the project is determined, the working boundary of the project is determined, and the project objectives and main deliverables of the project are also determined. For the information system integration project, if the project scope cannot be clearly defined and effectively controlled, it will have very serious consequences. For example, the actual needs of the project include: the customer failed to clearly define the scope because he could not provide a complete and detailed description, resulting in the unavailability of the final solution of the project; On the other hand, the expansion or frequent changes of the project scope will affect the project cost and schedule.
According to the author's practical experience in taking charge of and participating in many projects, scope diffusion is a very terrible thing, and customers always want to realize all their needs in one system, resulting in bloated and unrealistic project results. It is very undesirable for customers to have an idea: "(The developer) put it there when it is done, even if it is not used. What if they use it later? " . In addition, in the course of the project, especially in the later stage of the project, customers constantly put forward suggestions to modify the handover system, and sometimes even started to change it just after redesign, and customers demanded to change it back or change it to another model. "bottomless pit" is the same feeling of most domestic project managers in information system integration projects.
"Why is the project always endless? ! "
Second, the cause analysis As the undertaker of the project, the project manager uses limited resources to complete the project with good quality and quantity within the specified time, which is the ultimate goal to satisfy the customers and the company.
But satisfying customers means satisfying customers' endless needs? Will this lead to the final failure of the project? We should analyze the root causes of the problems in the scope change.
1. When signing the contract, there was a lack of personnel familiar with the information system integration project, which led to the unclear description of the project objectives and brought confusion to the later implementation.
2. Both the client and the project team want to do the project well. However, customers may lack a comprehensive understanding of the information system project, and the project team may not fully understand the details of the customer's needs, and their understanding of the ways to realize the needs is also different. At the beginning of the project, both parties didn't realize that the communication was not smooth, which led to the problems exposed when the system was handed over.
List several specific problems encountered by the author:
A, customers of IT projects often think that computers are omnipotent. With them, they only need to input a few parameters and have nothing to worry about. In fact, any technology has limitations.
B. A customer knows that he needs an inventory management software, but whether to introduce a new inventory management idea or to follow the current model has not been considered, and the developer is already in place, so the project team is required to do it according to the current model first. Later, the customer wanted to change the management mode, and the problem appeared. Design changes lead to a large number of module rewriting, and the construction period is inevitably extended.
C, a customer asked for a "convenient" query about the location of equipment, so the developer designed an interface to query the location of equipment according to various conditions. When handing over the system, the customer found that it was not what he expected. The "convenience" of the original customer refers to the intuitive expression in the form of graphical interface. The project team had to postpone the development of this function for a few days. Project manager alliance article, in-depth discussion.
3. The members of the project team can't tell the real needs of customers from the needs of gold plating, and completely accept the customer's change request. Of course, this is also to satisfy customers, but in fact it may not be able to achieve the goal.
Third, the scope change management first needs to clarify the scope of the project when signing the contract, which of course requires people familiar with the information system integration project to participate in the contract negotiation. The clear project scope in the contract can lay a solid foundation for future work.
Secondly, the scope of the project in the contract should only be a rough agreement, which must be refined and deepened. The preparation of scope specification and scope management plan is an important part of it. Scope statement should include project demonstration, product introduction, main deliverables, acceptance criteria, etc. In addition, enough time must be reserved for the project team to investigate the detailed requirements, and put forward the work breakdown structure (WBS) and requirements analysis report. WBS can provide a benchmark for project performance evaluation and project control.
In the system requirements analysis stage, in-depth communication between project team members and customers is the key to the success of the project. However, misunderstandings between the two sides usually lead to communication difficulties. Mr. Liu Lijun of AMT summed up why, what and how, which can make communication smooth very effectively. Simply put, at the beginning of the project, the project manager first needs to examine what the customer has done for this project, that is, "why", so as to truly consider the system design from the customer's point of view; Next, we should summarize what the whole project is "doing" and each subtask, so that developers can grasp the general direction of the project content well; Of course, the most important thing is how to do it. For the information system integration project, it is definitely worthwhile to spend more time at this stage. There are also some tips: the requirement analysis report should be written in a way that customers think is easy to read and understand, and also help developers develop the system they really need; It's best for project team members to tell customers the demand analysis report in detail and reach an understanding. Communication means is very important here. In addition, after the requirements are confirmed, it is best for the customer's management to sign in writing as a sign to terminate the requirements analysis process, but it is by no means a means to refuse the scope change.
Fourth, effective change control The scope plan of a project may be good, but it is almost impossible to change it.
The project manager and the project team must realize that there is nothing wrong with the scope change itself. In fact, many times it will make your system more robust and practical. Customers usually can't determine all the requirements at the beginning, and the situation will change over time. If they can't adapt to the change, the final solution may not reach its due value.
But if the change is out of control, the consequences will be very serious, and even lead to the failure of the whole project. According to the research results of standish Company in 1995, the first three factors that most easily lead to the failure of IT projects are: lack of user participation, incomplete requirements and descriptions, and changeable requirements and descriptions, all of which are directly or indirectly related to scope change management.
Therefore, scope change management must be carried out. Mr. Pan Dong believes: "The purpose of change control is not to control the occurrence of changes, but to manage changes and ensure that changes are carried out in an orderly manner."
In order to implement change control, an effective scope change process must be established. This process should include confirming the change, evaluating the business value of the change, analyzing the impact of the change on the project, and submitting it to the project sponsor for evaluation to determine whether to implement the change.
However, only the scope change process is not enough to really control the change, because there is a lot of pressure outside the project team and it is closely related to the lack of effective change control means. This article is transferred from the project managers' alliance.
At present, the popular change management thought holds that there are four key points in the process of scope change that must be strictly controlled, that is, who has the right to confirm the change, what kind of change needs to be implemented, how big the impact of the change is, and whether the customer accepts the cost of the change.
1. Who has the right to confirm the change:
Customers' business people should not be allowed to contact developers directly to save time, so they can't control the changes. It must be made clear in advance who the customer has the right to make the change request and who the project team has the right to accept the change, and the change request must have written materials.
When I participated in the implementation of a large-scale information system integration project, I was deeply touched: the project manager once reminded us that customers should pay us to implement it, which should be regarded as a "public to public" thing. If the user asks to change the scope on the grounds of "personal feelings", the developer can refuse. Project manager alliance, project management issues.
At that time, if users found that the demand changed due to business changes, they needed to submit a written application to the customer's project leader, and after the project leader approved it, they would hand it over to the implementer's project manager.
So that the project leaders of both parties can know all the changes. Moreover, users are more cautious when submitting written change applications, which are generally carried out after discussion within their own departments, reducing repeated changes caused by different internal views of users.
2. What changes need to be implemented:
Not all changes need to be modified, and not all changes need to be modified immediately. Scope changes proposed by customers must be reviewed to decide which changes need to be modified and when.
Customers generally don't know much about information system integration projects and think that simple things may be complicated by computers. Therefore, project managers and project teams should calmly analyze what users want to achieve and grasp the essential needs. If the user's suggestion is difficult to realize, you can communicate with the user and ask him if he can achieve his goal by other means.
According to the author's experience, generally speaking, the user's demand for gold plating can be postponed or even ignored. If the new requirements of users do not affect the realization of core business, they can be arranged after the existing functions are improved.
3. What is the impact of the change?
All members of the project team should realize that change comes at a price. It is necessary to evaluate the cost of the change and its impact on the project, so that customers can understand the possible problems of the change and judge whether the change should be made together.
For more information about project/service/procurement bidding, and to improve the winning rate, please click on the bottom of official website Customer Service for free consultation:/#/? source=bdzd