Ok, now i am back and i apologize for the long absence, so today’s post is about that group of stakeholders who we collectively refer to as customers or clients. did i say a group of stakeholders?? yes and let me explain why and how, the way i look at a client group is in terms of,
1. Who has initiated the implementation
2. Who owns the product being developed and knows what is wanted and can verify if the developed product fits the bill
3. Who is actually going to use the product developed at a transaction level
so we can now identify the three categories of stakeholders as
1. The Project Sponsor
2. Domain SME and/Or UAT InCharge
3. The End User
and we know that the Project Sponsor is the one that gives the go ahead for the implementation after recognizing the business need for the same and initiates the project, holds and controls the budget and is in charge of the project at the highest level. and the documents and updates he/she would ideally look for would be the Business Requirements document detailing the business needs and the solution discussed, proposed and agreed upon for the same and once the project cycle kicks in, the sponsor would typically be sent regular (weekly / twice a week are ideal) mails updating the status of the implementation and would preside over Steering Committee calls or meetings where go / no-go decisions would be taken in case of conflicts.
And then we have the Domain Subject Matter Expert who actually knows the nuts and bolts of the business processes being automated in the project implementation, this person would typically comb through your Business Requirements document in detail and ensure that all sunny day and rainy day scenarios have been captured for each business process (and send back the BRD with the comments in Track Changes if not :)), review all the test cases with a hawk’s eye and would engage in discussions on the report templates to be used, the recipient lists to be included in mails, the labels for the text boxes and all such bells and whistles, he/she usually would also be part of the User Acceptance Tests and would be one of the stakeholders signing off on the UAT. This stakeholder(s) would typically be in constant touch with the BA and the Project Manager through daily status calls and/or mails.
Next up are the people that will actually have to use and live with the product under development, the end users, these set of stakeholders may or may not read through your BRD depending on the practices followed in the business organization, some of them may be part of the group engaging in the UAT and would thus receive and review the test cases and almost all of them would be part of the training workshops that you may conduct for product familarisation and would be using the user manuals that are prepared as part of the project deliverables.
So you see we have a set of stakeholders on the same side of the table who can be visualized as different subsets with different expectations and different needs.
Next I will share my understanding of the stakeholders on the other side of the same table and their expectations, till then see you around.