They are important customers of the company and cannot be ignored or rejected.
1. The development schedule requires a detailed time schedule in minutes, such as an itinerary.
Hidden reasons:
By providing a detailed schedule, customers are trying to minimize waste and reduce costs.
2. The trail is forced to be checked by hand. Do not allow automatic checks in the system.
Hidden reasons:
Customers do not believe in automatic checks in the system. Customers believe that the best human confirmation is the best.
3. The customer speaks the requirements vaguely, so you will not get accurate information. And when you point out that it's ambiguous, the customer gets angry.
Hidden reasons:
Customers dare to communicate their requirements vaguely and extensively, and ask the project team to start over and fix them when checking product quality. Saving Changes...
Try to find out the underlying reasons through techniques such as 5 Whys. Once you have an idea what the interest is underlying the position, you are in a better place to be able to come up with options to satisfy those interests in ways which don't put your project in jeopardy.
First of all, this is a project I have experienced in the past.Please be assured that it is not the current story.
And this discussion has implications for making sure that the choices I made in the past were better.
To add to the description, this is the initial state of taking over the project that had its predecessor.
In that sense, I think 5 Whys' approach to problem solving is very appropriate.
Ultimately, I realized that all was due to lack of trust. It is not easy to restore trust once lost.
In the end, my choice was to meet customer demands thoroughly until trust was restored.
Despite significant cost and schedule delays, the project was barely completed, but customer satisfaction was not increased.
Do you think there are other good options? Saving Changes...
Alexandre CostaScrum Master| Integer Consulting - Pictet technologiesLoures, Portugal
Hi Takeshi San,
The stakeholders sometimes could be very difficult, in your case it sees that your customer is very conservative , this caracteristic is something that is hard to change, you can only trying to understand and assure that all his concerns will be addressed.
How I understand you about vaguely requirements already been there, is not easy try to discover indirectly what the customer wants and why is acting like this, following the technic specified by @kiron is a good step.
In my area (software) when this happens normally I take some time with the team to make mockup's or a prototype to present to the customer to obtain some feedback and engage the customer with the choices is making after seeing something, is a good time to detail the business requirement document with is ideas as a participant and signing the document gives his agreement signal.
Trust is hard to restore, but if you have a document signed by him , with the choices his made he cannot denied, sure he can also say that his opinion changed but in this case he must be aware of the repercussions in the schedule , cost of the project and be ok with that.
Alexandre
...
1 reply by Takeshi Miyaoka
Feb 08, 2020 4:09 AM
Takeshi Miyaoka
...
Hi Alexandre,
I think mockups and prototype approaches are specific and very good. so I did exactly that, but the suspicious customer did not sign with permission.
That's because signing makes it clear that additional requests will not be accepted. He was angry when I explained that I could not proceed without the signature.
Eventually, proceeding without a sign resulted in new requirements for the description of the fix and schedule delays.
The stakeholders sometimes could be very difficult, in your case it sees that your customer is very conservative , this caracteristic is something that is hard to change, you can only trying to understand and assure that all his concerns will be addressed.
How I understand you about vaguely requirements already been there, is not easy try to discover indirectly what the customer wants and why is acting like this, following the technic specified by @kiron is a good step.
In my area (software) when this happens normally I take some time with the team to make mockup's or a prototype to present to the customer to obtain some feedback and engage the customer with the choices is making after seeing something, is a good time to detail the business requirement document with is ideas as a participant and signing the document gives his agreement signal.
Trust is hard to restore, but if you have a document signed by him , with the choices his made he cannot denied, sure he can also say that his opinion changed but in this case he must be aware of the repercussions in the schedule , cost of the project and be ok with that.
Alexandre
Hi Alexandre,
I think mockups and prototype approaches are specific and very good. so I did exactly that, but the suspicious customer did not sign with permission.
That's because signing makes it clear that additional requests will not be accepted. He was angry when I explained that I could not proceed without the signature.
Eventually, proceeding without a sign resulted in new requirements for the description of the fix and schedule delays. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
With all my due respect, It is not right that "Customers dare to communicate their requirements vaguely and extensively, ". What people must know is customer never communicates requirements. They communicate needs/wishes/desires/wants that people that work with requirements (business analyst mainly) must transform into requirements. From product/service/result requirements (business analyst is accountable for that) project requirements are defined (project manager is accountable for that). Both are the components of the solution.When you understand that then it is not way to fail.
...
2 replies by Takeshi Miyaoka
Feb 08, 2020 6:22 AM
Takeshi Miyaoka
...
Feb 08, 2020 6:24 AM
Takeshi Miyaoka
...
Hi Sergio,
You're right.
Defining the scope and finalizing the requirements is important and a principle to avoid failure.
The customer may make vague and vague explanations to make additional requests later, but this should be eliminated wherever possible.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Dear Takeshi
Interesting these questions of yours
Thank you sharing
Before giving my opinion, what was the service provision contract?
...
1 reply by Takeshi Miyaoka
Feb 08, 2020 6:25 AM
Takeshi Miyaoka
...
Hi Luis,
Contract for the provision of software and hardware.
With all my due respect, It is not right that "Customers dare to communicate their requirements vaguely and extensively, ". What people must know is customer never communicates requirements. They communicate needs/wishes/desires/wants that people that work with requirements (business analyst mainly) must transform into requirements. From product/service/result requirements (business analyst is accountable for that) project requirements are defined (project manager is accountable for that). Both are the components of the solution.When you understand that then it is not way to fail.
With all my due respect, It is not right that "Customers dare to communicate their requirements vaguely and extensively, ". What people must know is customer never communicates requirements. They communicate needs/wishes/desires/wants that people that work with requirements (business analyst mainly) must transform into requirements. From product/service/result requirements (business analyst is accountable for that) project requirements are defined (project manager is accountable for that). Both are the components of the solution.When you understand that then it is not way to fail.
Hi Sergio,
You're right.
Defining the scope and finalizing the requirements is important and a principle to avoid failure.
The customer may make vague and vague explanations to make additional requests later, but this should be eliminated wherever possible. Saving Changes...
Before giving my opinion, what was the service provision contract?
Hi Luis,
Contract for the provision of software and hardware.
...
1 reply by Luis Branco
Feb 08, 2020 11:21 AM
Luis Branco
...
Dear Takeshi
I was referring to the type of contract:
Fixed price?
Time and materials?
Price and incentive?
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Takeshi,
you state it yourself, the core issue is lack of trust and therefor the only ideas that come to their minds is deep scrutiny, wanting to have a human to blame for failure and avoidance of commitments (your points 1-2-3). These are behaviors coming from fear.
You can follow these ideas and maybe build trust, but I think it is time consuming and results in a lot of waste. And it creates distrust again since you will fail on some detailed commitments.
So I would look at other means to create trust too. Trust is resulting from fear turned into hope. Showing bright visions about the future. Making you, the project manager, a trusted person means to go thru some examples of your predictions / commitments that become a reality, giving them experiences. They (all humans) need positive experience to feel hope. If you can help them get these experiences you will become trusted, step by step.
Practically, go to Karaoke, go drinking, drive them to a unknown but pleasant location, invite them to nice restaurant, give them a pleasant surprise every day, establish a symbol for hope (a song, a mascot, a comic figure - something you share with them).
Change their feelings, do not try to convince them with logic. Logic cannot remove fear.
BTW - will be in Osaka end of March, speaking to the Kansai branch of the PMI Japan Chapter on 28.3. morning.
...
1 reply by Takeshi Miyaoka
Feb 08, 2020 6:28 PM
Takeshi Miyaoka
...
Dear Thomas,
The approach you presented I felt very comfortable.
No matter what the circumstances, never forget the importance of being positive, cheerful and kind with hope.
Extorted logicals bring anger to those who fear. This is probably the reason for this example.
Are you coming to Japan? It is wonderful. March is still chilly but enjoy your stay in Japan.
