Comic Chinese Style Project Management

Chapter 3 Project Requirements
1.1 Project requirements analysis is "business-oriented"
If you carefully analyze every failed project, the reasons for the failure of the project are more or less related to the requirements analysis of the project.

When you sit down with users to discuss requirements, what should you talk about?
User: "We want to build an office management system."

Project Manager: "What functions do you want to implement?"

"How many people are using it at the same time?"

"What database platform do you want to use?"

"What does your current IT architecture look like?"

Are these questions right?Technically speaking, there is nothing wrong, but the angle is wrong, or the entry point is wrong.Project managers generally have a good technical background, but project managers are not chief engineers, architects, or programmers, but should be a "business-level manager."The entry point of project requirements must be at the business level.

"Excuse me, why did we establish such an office management system?"

"What is the main business problem we are currently facing?"

"What business problems would you most like to solve with this system?"

As a project manager, when you choose a technical solution, develop a project plan, and determine acceptance criteria, the customer's "business goals" are far more important than "technical realization".The first thing to figure out is why, not how.

case thinking

When your customer tells you, "I want to buy a TV." What question should you ask him?
1.2 Is what the boss says must be reliable?

The boss calls you into the office and gives you an important project: to upgrade the company's production management system.He hopes that through this project, the customer's order response time can be greatly reduced from the current 72 hours to 24 hours.

The boss tells you his ideas incessantly, why to do it, how to do it, who can help you... After 2 hours, you memorized 3 pages.

What's the first thing you do when you step out of your boss's office?
Maybe you will think of many things, plans, documents, resources...

But have you ever thought: Is the idea your boss tells you necessarily reliable?

What is the most important part of needs analysis?It is a "demonstration of feasibility".

The boss hopes that the business department can respond to an order within 24 hours. You need to communicate with each relevant department seriously. What does the boss hope to do?What is the purpose?What does he wish to do?What do you want your department to do? ...

You'll find that the feedback varies widely:

Some departments: "No problem, we can definitely do it!"

Some departments: "Impossible, the boss is talking nonsense, he doesn't understand the situation at all!" Other departments: "The boss has arranged this way, we must do it!"

However, you think in your heart that they will definitely not do it...

Sometimes what your boss (or your client) tells you is just an idea, an idea.It's not that the boss is not as smart as you, but because he sees things from a different angle than you.You need to help the boss (or client) to demonstrate the feasibility of this idea.

what should you do

Communicate with everyone and form your own thoughts and ideas.

Can the boss's idea do it?If so, what resources are needed?If this idea is not realistic, what is more realistic?What resources do you need according to your thinking?For example, if it is too difficult to respond to orders within 24 hours, do you think 48 hours can meet the business needs of the company?
When you have your own ideas, go to communicate with your boss:
"Boss, I have summed up your thoughts. What you want is... Is my understanding correct?"

"I communicated with several departments, and their feedback is..."

"I think the main difficulty is..."

"My suggestion is... do you think it is feasible?"

The boss may accept your ideas, may give you some new suggestions, and may even give you enough resources and authorization to make the impossible situation possible... After all, he is the boss.

As a project manager, needs analysis should not be to sit down and have a few meetings, record everything the boss (customer) said, and then take the few pieces of paper you wrote down as project requirements.Demand comes from repeated communication, and sometimes the boss may not clearly know what he wants and what problems will arise.

Demonstrating the feasibility of the project and implementing the idea of ​​the boss (client) is the primary task of the project manager.

1.3 Requirements need to be confirmed
Through communication with management, you form a requirements document for the project.

You organize the requirements document and take it to the supervisor...

"Boss, here is the requirements document for this project, including the acceptance criteria. Can you see if there is any problem? If there is no problem, please sign it..."

Do you think the boss will sign it?

If he signs it quickly, that's great, he has a plan in mind, he approves of your project, and your project has a very good start.

What if he doesn't sign it? (In many cases, not signing is a high probability event.)
A simple question, why is the boss unwilling to sign?Let me tell you the most likely scenario: He didn't think it through himself.

"You do it first, and we'll see after we finish a part."

"You are the project manager, you can decide..."

Sure, you're the project manager, but you're not the client, you're not the boss, and it's not you who really determines the project's needs.

Knowing that the boss is unwilling to sign, why force him to sign?
What we really want may not be his signature, but to force him to think seriously about the project.In many cases, if you don't force him, the boss will not seriously consider the problem for you, and the ultimate responsibility lies with you.

The project manager needs to be "strong", but not "tough", and use every possible method to "force" the boss to think clearly with you.You can ask him to sign, you can be soft and hard, you can understand it with reason and move it with emotion...

Whether it is a client or a boss, don't be overwhelmed by their strength.As long as you are doing the project well, under normal circumstances, they will understand.In short, no matter what method is used, before the project starts, the main project stakeholders (Sponsor) must agree on the project goals and requirements.

1.4 Who is the real Sponsor?

Is there such a situation? You have communicated with a vice president of the customer many times to determine the detailed requirements of the project and form a document.

But when the document was reported to the president, it was completely overturned, and everything started all over again...

During the high-level review, it is normal if there are small adjustments, but if it is completely overturned, what does it mean?
It means that you have found the wrong person to talk about the requirements... Many people who you feel easy to communicate with may not be the real Sponsor of the project...

If it is an R&D project, do you think it is correct to communicate the requirements with the technical director of the client’s R&D department?

Note: Sponsor refers to the person who has the final decision-making power in the project, and they control the funding, acceptance, etc. of the project.In most cases, the demand does not come from the technical department, but from the business department.As a project manager, you must be able to elevate yourself to the height of business, and have the ability to communicate directly with people at the business level.

The difficulty is that business-level requirements are often uncertain, vague, even contradictory (from different departments), and often entangled with the interests of all parties.And you must have the ability to sort out, communicate, clarify, coordinate, compromise, and finally reach a "relative consensus."

For some important sponsors, even if you can’t meet often, you can get their feedback smoothly through email, text message, QQ, or even find someone else to convey.

The communication needs must be aimed at the sponsors of the project. Even if it is indirect, you must be able to talk to these people.

1.5 Quarrels and Arguments in the Requirements Phase

Case
The goal of the project is to help clients develop a business management system.It is certainly a reasonable requirement for the customer to require internal staff to be trained after the system goes live.But when you refine the requirements, you find that customers want to train a large number of front-line employees, many of whom have never touched computers. That is to say, customers want you to start training from hardware and operating systems, not just the applications you are responsible for developing.

For such a training request, do you agree or refuse?

·If you have enough budget and time in your hands, there is nothing wrong with agreeing to this request.

·If you don’t have the budget and time to refuse the customer’s request, as long as you communicate well, there is nothing wrong with it. After all, there are many such basic computer trainings in the market, and customers can easily find alternatives.

It seems right to agree or not to agree, so what must be wrong?
The really wrong approach is that you know that customers have this need, but you don't make it clear, but put this demand "virtually" there.Maybe the client didn't strongly demand that this be written in the contract, but it wasn't agreed upon at the beginning of the project.

Even sometimes, the customer didn't think about it, but you realized it. At this time, do you want to discuss this issue with the customer?
Many times, we don't want to entangle some problems with customers prematurely, just because we are afraid of trouble.If we don't talk about the present, we can proceed relatively smoothly, but once we talk about it, things may become more complicated...

I dare not say that this kind of thinking is definitely wrong. Sometimes it is technology to talk clearly, and it is art not to talk clearly.As I said before, artistic things are not reproducible, and this is beyond the scope of this book.

Technically speaking, one thing is certain. If it is indeed a problem, it will be inevitable sooner or later. If a quarrel is inevitable, it is better to quarrel sooner than later: expose the problem as soon as possible, and you can work with peace of mind after the quarrel is over.

If you get into a serious disagreement at the acceptance stage, neither you nor the other side has much leeway.

1.6 "Exposure Agreement" on project contracts

Case
The entire implementation process of a certain project is relatively smooth, but in the acceptance stage, the customer refuses to accept it according to a certain clause in the contract, resulting in significant delays in the project and serious cost overruns.

There must be no so-called "open agreement" in the project contract, that is, terms that cannot be quantified for acceptance.

Is it reasonable if the terms say "the system must meet the customer's business needs"?This is a typical clause that seems very reasonable but has no operability.You can mention 100 "business needs" today, and 500 "business needs" tomorrow, and the project team will never know what your "business needs" are.

Requirements must be quantifiable and actionable.For example: "The system should ensure that 200 people can operate online at the same time..."

Other typical "exposure clauses" include: customer satisfaction, quick response, stable operation, effective control... (What is satisfaction? How long is fast? What indicators does stability refer to? How is it effective?)

The failure of many projects is doomed the moment the contract is signed.

1.7 Superficial reasons and deep-seated reasons
Is there such a situation, when you eloquently proposed a very good plan to the client (boss), but was rejected by the other party with a high-sounding reason?
We have always emphasized that project managers must have very good communication skills, but communication skills do not mean talking endlessly. In many cases, calming down and listening is a more important skill.

The more experienced project managers (such as project managers with technical backgrounds), the more willing they are to impose their own ideas and thinking on the other party when communicating with customers, because they are overconfident in their experience and abilities and ignore It understands the "real" ideas of customers, especially many non-technical and implicit ideas.

Case
As a project manager, you suggested that the customer adopt a low-cost technical solution, and demonstrated technically that the solution can fully meet the customer's business requirements.But the customer is clamoring for a more complex technology platform, and you and the user have a heated debate about this issue.

Customers think: cost is not a problem, the key is to have good performance and reliability.

You know very well: this solution is unnecessary and brings potential technical risks.

What could be the real reason?What should you do?

We don't discuss "arguing with customers" itself (I don't think you can't argue with customers), but discuss a more fundamental question, why do customers insist on more complex systems?This is not necessarily a technical question in itself.

This is a real case, and finally we learned what the customer really thought: he just didn't want to be the first to adopt this simplified solution within the enterprise, and he didn't want to be the first to eat crabs.In other words, he is just sticking to a course that is safest for himself.

In the demand process, what you need is patience, skill and in-depth communication to find out what the customer really thinks.Don't try to "convince" the other party from the technical level, maybe the problem itself is not technical.

The most important communication skills in the demand process are guidance and listening, and expressing one's point of view can only be auxiliary.

(End of this chapter)