Second, the budget should not be calculated in full. After I make a budget, I always give a discount when I tell others my budget. For example, our company implements an ERP project, and the implementation consultant of the other party asks me, what is the budget of our project? According to my budget in advance, I planned that the software licensing fee was 600,000 yuan, so I told him that according to the above arrangement of our company, the software licensing fee was budgeted at 500,000 yuan. Why? Because if you reveal your background from the beginning, then the other party will bid on the spot. Originally, we only needed 600,000 license fees, so we said 700,000. Let's bargain again. In other words, many software companies quote according to our budget. If our budget is high, their quotation will be high. If our budget is low, their initial offer will be lower. Therefore, when we control the budget, we should not show our background to others immediately, but make a discount first, so that we can have room for manoeuvre in the work we need later. At the same time, don't be fully prepared for the internal cost budget. For example, when making a budget with great uncertainty such as secondary development expenses, we should leave some room for manoeuvre. For example, the cost of secondary development is generally 65,438+00% of the software cost, that is, 60,000, according to the previous demand survey or the suggestions of software companies. However, it is difficult to accurately estimate the cost of secondary development, so when considering these uncertain costs, we should distinguish between levels. For example, when I consider the cost budget of this secondary development, it is divided into three levels, namely 30,000, 20,000, 1 10,000. If the cost of secondary development is less than 30 thousand, it can basically be met. If they ask, let the software company be responsible for the development; If the total number exceeds 30,000 and reaches the yellow warning line, the user's secondary development needs will be reviewed again to see if secondary development is needed; If it has exceeded 50,000, it is my red warning line. At this time, if there is no boss-level approval, or the consultant does not strongly recommend the development of the case, they will generally not accept their needs. This control has two advantages. First, in order to meet their own needs, enterprise users will take the initiative to consider the problem and understand the system, because only in this way can they submit the requirements at the fastest speed, and the chances of being adopted for secondary development will be much greater. This can also invisibly promote the progress of ERP projects. Second, when they all put forward their demands on their own initiative, I can master as many secondary development demands as possible from the beginning, which is conducive to my unified arrangement. At the same time, the demand for one-time development is more, there is room for bargaining between them, and the big discount will be much larger. So, of course, we are happy to do such a versatile job. Three, for the change of project requirements, should strengthen control. In fact, as far as I know, a large part of the budget overrun of enterprise informatization projects lies in the change of project demand. According to relevant statistics, the cost generated by the change of project requirements accounts for about 20% of the total project expenditure, which shows that this is not a small expenditure. If we can reduce the loss of project requirements change, it will undoubtedly reduce the problem of excessive project support. Therefore, the key of project budget control lies in the control of project demand change. However, most of the time, it is impossible to eliminate the changes in project requirements. Due to various reasons, such as insufficient preliminary research, unexpected changes encountered by enterprises in the process of project implementation, the proposal of new user requirements during the project process and the continuous improvement of the system after the project is completed, it is possible to cause changes in project requirements. In order to reduce the loss of demand change, I generally take the following measures during the project implementation: 1. Transfer the loss of demand change to the developer as much as possible. China's language and writing are good, and a clear sentence may make people have different understandings. In case the requirements change, try to return the responsibility to the developers, saying that it is a loophole in their program development and a problem with their software. The needs we put forward are some basic needs, which do not belong to our personal needs, but problems that we often encounter. If we are tough, the developers will give in. But pay attention to the scale, and don't let developers think that we are unreasonable. 2. treat customers as my customers, not employee relations. In the implementation process of informatization projects, there are generally three parties. One is the user of the terminal, the other is the person in charge of our project, and the third is the implementer or software vendor. In fact, many problems exist between Party A and Party B.. Because of the end customers, sometimes the demand is not clearly considered, which will lead to the change of demand in the later period. This is mainly caused by the lack of pressure from end users, who will think that we are responsible for our own needs. It is because they have this idea that sometimes when they want something, they ask it as soon as it is hot, without careful consideration. So when users make requests, I usually ask users to write them in writing and sign their names. Because before writing, they will definitely think about their own needs before writing. It is very likely that in this process of thinking, users will change their original intention. At the same time, the changed requirements need special approval. Because according to the law, the user's first impression is often more accurate. Therefore, when users put forward demand changes, we should throw cold water on them to wake them up. Project budget control is a skill that reflects CIO's ability. Many people say that information engineering is a game of burning money, which is absolutely true, but it also has its reasons. If the project budget is out of control, even if the project is finally successful, you, as the person in charge of the enterprise project, will have mixed feelings at most; If this project fails, you are even more to blame. Therefore, to be a good CIO and a good information project leader, we must start with the project budget control and do our best to ensure that the project budget is not out of control, otherwise, you will be even more sad. It is a shameful thing to apply for project funds from the top leader when the budget exceeds.