I was consulting a client which was a Dutch multi-national.

We were re-vamping the existing system as it was built on legacy technology. It could not handle our business needs and was also quite expensive to maintain.

We were in UAT and this is what happened.

Suddenly, one key stakeholder came up with a requirement which was not designed into the solution. This could potentially delay the project by another 2 months.

There were a number of project progress review meetings. The project had also covered 80% of the planned schedule and effort.

This particular stakeholder did not bother to attend any of the review meetings.

Neither did he raise any objections to our MoMs.

This was a business rule which could have been discovered if the stakeholder was involved in the project earlier on. This business rule also had a significant impact on how the data migration would be conducted and tested.

Have you encountered such scenarios?

Due to some reasons, some stakeholders wake up quite late in the project.

They probably believe that the original schedules would anyway be extended and they can incorporate their requirements in the last minute. After all, the project is for the benefit of stakeholders.

How should we BAs handle such scenarios?

I trust stakeholder charter is a good approach to handle the situation.

Here is a charter that I created:

1. All stakeholders shall deal with all other stakeholders in a dignified professional manner and treat each other with civility and respect
2. All stakeholders shall agree to the fact that the business environment is dynamic and hence the project objectives and priorities may change as business dynamics changes. However, all stakeholders shall also agree to the fact that uncontrolled changes can ruin the project and agree to follow a defined change control mechanism.
3. All stakeholders shall agree to provide other stakeholders with the level of commitment and support expected in terms of time and effort well in advance, say a minimum 2 weeks
4. As an effective team, all stakeholders agree that the issues will be judged on the merit of the issues only
5. All stakeholders shall co-operate and support each other to make the project a success
6. All stakeholders shall raise any concerns about the project or the process with City staff in an open and timely manner
7. All stakeholders shall agree to attend all review meetings
8. All stakeholders shall agree to provide prompt approval/objection to the requests. 

Have you tried any other approach? Did it work for you? We would love to hear your experience.

Having said that, there was another discussion that I stumbled upon -  Are Hackers Our Stakeholders?

As business analysts, we have been taught a thousand times that stakeholders are extremely critical for obtaining system requirements. We know our stakeholders are Sponsor, End users, Domain SMEs, Suppliers and possibly government organizations for statutory reporting and legal compliance.

However, do we consider someone whom we may never meet and who would NEVER express their intents as potential stakeholders?

For example, do we consider hackers who are always on the prowl to steal sensitive data from our systems or may even steal money from our system as potential stakeholders?

Same way, there could be stakeholders who have a malicious intent to carry out transactions beneficial to them but can be harmful to the organization.

I have come across a real-life incident where a procurement person paid millions of dollars to fictitious suppliers which were created by himself.

Are you aware of techniques to identify such undesirable stakeholders and anticipate their moves so that we can make our applications safe and secure?

We would love to hear your experiences and suggestions regarding the same.