Requirements Change Seven Step management method

Typical scene: Recently more annoying, annoying customers! We are now doing an e-government project for the Changjiang government, which has a function of online marriage application registration. Because the previous national policy has canceled the mandatory physical examination this link, therefore our work flow also changes accordingly.

I didn't expect the customer to get inspired: many of our work flow after the possibility of change is very large (such as policy adjustment, department changes, leadership reorganization, etc.), simply give us a customizable function, we mention a maximum set of functions, you have done our own can change on demand, well, so good!

But it's a disaster for the project team. Because customizable functionality often means a doubling of the workload!

Analysis: First of all, let's talk about this phenomenon of coping methods. The most typical is to solve the problem by communicating with the customer. How to communicate? Because contracts for software projects are difficult to define precisely at the beginning of a contract, it is not helpful to rely on a contract.

I talk to the bosses of many IT companies and I joke that our IT companies are the Qing government. Why the Qing government? One of the characteristics of the Qing government is that there are too many humiliating treaties. Everyone often only wry smile: What method, the customer is anxious is a subtext: do not do, do not want to do away! I want to do a lot of companies.

So you see the contract is useless, then how to do? It is usually through emotional contact to win customer sympathy. As mentioned in the scene above, it is unreasonable requirements, but customers will also quibble ah, "Why do not give us, this is within the scope of the contract work!" ”。 Because the original only said to implement the workflow, but not to mention the custom workflow is not counted. The problem comes out and see how to do it.

Of course, if you now encounter similar problems, your organization can be juchongruoqing, then you do not have to look down. We often hear a word is "reasonable", we say that there is nothing strange ah, cliché! However, this statement in the software project Change management has a unique form of expression. It's important to communicate emotionally with your client, but you notice that it only works half the work and that half of the work needs to be reasoned. People will refute me and say: what reason! Our client is God, let you do what you do! There's so much nonsense about you.

I noticed a social phenomenon: the direct project leader of the client side tends to have a youthful tendency in age--most of the thirty or forty-year-old. What are the characteristics of these people? First of all, they tend to have formal education in terms of education, so they are more reasonable--or because they are not tall enough (joking)? Second, these people really want to work on the results. When a project encounters a negative risk, they are willing to convince their leaders rather than not to do so.

It is based on the above two points of analysis, we first introduce the requirements change management method-change management seven steps. The seven-step method confirms the project management trilogy I've always advocated: refinement, quantification, and graphics, and the seven-step method mainly validates the necessity and benefits of refinement and quantification. Let's take a look at the following picture:

Everyone saw that: Oh, it is the project management triangle, what to pull it. The scope can be understood as the amount of content that a project needs to be completed, while time quality and cost means the time cost and the corresponding quality level that must be invested in the task of accomplishing so much content. Let's look at the following picture: