And The Other Side Of the Table……..

Hello there, i am back and so today it is about the folks who actually get their hands dirty and bring a business vision to life,

So on this side we have the players categorized as follows:

1. The team that actually builds or develops the product based on the business vision you share with them
2. The team that will eventually hold the product and provide support to the end users on a daily operational basis
3. The team that validates if the developed product is as per user specifications
4. The teams that validate if the product being developed is as per best practices and the standards being followed in your organisation
5. External Suppliers of software or services

and this translates to,

1. The Project Manager
2. The Operational Support Team
3. Quality Team
4. Implementation SMEs
We have the Project Manager and his development/build/implementation team, as is obvious these folks develop the solution, the PM creates the Project plan, Work Breakdown Structures and the Activity checklists. The go-around document for this team would be the Low Level Design document or Technical Specifications document which is a byproduct of the Functional Specifications document that you share with the PM, User Training Sessions and Manuals are brought out by this team(the functional memebers of the team usually do this) and this team also transitions the functioning of the nuts and bolts of the product to the Operational Support Team, the support team takes over the maintainance once the product has stabilized and undertakes fixes and enhancements through Change Requests.

In between the product being developed and pushed into production, it is put under the scanner and ripped apart to check for flaws, disasters and catastrophes, i know you love this phase, yes the product is tested and depending on the functionality and other parameters like the probable number of users, internet facing or not etc, the product is subject to functional, load and other applicable types of testing, If the product under consideration involves a couple or more applications publishing data among themselves, a thorough System Integration Testing is carried out. Depending on how your organisation works, either the BA or the Quality guys write the Test Cases. Quality teams use the Functional Specification document and the Technical Specification document (in most cases) and maintain Defect Registers & Trackers.

Depending on how your organisation works, the Solution Architects, the DBAs, Usability Analysts, Change Consultants, Information Security experts et al are brought in either before the implementation starts or after the initiation and before the development commences. These guys use either the detailed Requirements Document or a Solution Approach document.

This outlines what goes on and around in a typical software development cycle, when a methodology like AGILE is followed and adhered to, the players , the process and the artifacts change, and more about that later……

So until next post, take care………

One side of the table….

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.

How will you say what you have to say

Did I confuse you with the title of my post, I apologize if I did, what I wanted to say was what my manager always says, “how you say something is as important as what you say”, so the point is if you have an use case to explain the way you present it to the target audience is nearly as important as the use case.

In my previous post I was sharing my experience of looking at a requirements gathering session wearing a different hat, I will continue from there and so now that I have the requirements documented with me and the business user’s vision in my head how do I go about sharing this with the various other stakeholders involved in the implementation and how will I go about doing this, that is how will I say what I have to say[Symbol].

So I have completed a requirements gathering workshop and the next steps would be that I would get the business user who was part of the workshop to agree on the requirements that I have documented so that we are sure that we are In sync. Apart from the daily minutes circulated at the end of each day of the workshop, a comprehensive requirements document is shared with all the major stakeholders and once they give the go-ahead on the same, the gates will now be opened to welcome other stakeholders into the implementation. We will look at this situation involving many players from different streams next but before that a question would be how do I structure my requirements document aka the BRD, the Business Requirements Document, as it is intended for the business user I would elucidate on the requirements from his/her angle, the headings I would typically include in the BRD would be the Objective of the application envisioned, the Benefits the Business would accrue from implementing this vision, the pain areas and the inadequacies of the current system (could be manual and mail based in many cases) that is making the business to look for an alternative, how the application being considered for implementation would address these concerns from an operational, administrative and executive angle and finally the business processes involved in the implementation.

And returning to the scenario where the business has given the go-ahead based on the BRD, the other stakeholders now have to be run through the requirements,  one such stakeholder would be the Project Manager and QA Manager identified for the implementation, then the Information Security or similar team in the organization who will typically study , understand and identify the data security threats and issues of the implementation in question, this according to me is an important stakeholder as now organizations are going the Cloud way, your organization will have certain guidelines and these are the best guys to assess your implementation vis-à-vis the established guidelines, the architects would be another team that you will bring in at this stage to study and approve the solution you are suggesting or recommend an alternate. Now would I share the same document with all these folks? Obviously not.

The Project Manager and the QA guy would expect the requirements spelled out comprehensively in the form of a Functional Requirements document which would provide the framework for their Technical or Low Level Requirements document and the Test Cases Repository, the Information Security team would prefer a modified version of the BRD with more emphasis on how the proposed application would interact with other application and the internet, and the architects would like a Solution Approach document which talks about the functionality of the application, details of the software (including the RDBMS if applicable) that will be used, the intended workflows and their touch points within and outside the proposed application and perhaps the load the system is supposed to handle on a daily basis, monthly, quarterly and annual basis (this is very important for Financial applications) and also the anticipated increase in the number of users on a yearly basis.

So this roughly is an outline of how I would typically handle my post requirements workshop tasks and life [Symbol] , and more on the various stakeholders, their expectations and the documents they would want from a BA in my next post….

Be Right Back folks…..

A Change in Perspective

Let me start with a very profound quote I came across today, it said “Any ending is a true beginning”.

Would you be very surprised if given a situation and fixed set of parameters you would think in two very different ways depending on the hat that you are wearing, a high five if you would dear reader and this post details how my thinking changed when I transitioned from the role of a Project Manager to a Business Analyst.

It was my first requirements workshop as a BA, the tool being demonstrated before the actual user requirements would start being discussed and documented was an assessment utility to fit into the organization’s training landscape. My first moment of surprise was when I realized I was actually looking at the features the utility offered without comparing it to PeopleSoft HRMS (for the record it is my favorite ERP and gold standard for a HCM application till date and no I have not worked on Workday yet and that I promise is a story for another post). In my past life as a PM I would compare the utlity to PS HRMS endlessly, feature wise , user interface wise endlessly.

And my next moment of surprise arrived when we got down to discussing the interfacing of the assessment utility with the legacy applications, as we were working out the brass-tacks of the cross application interface and the changed thereof in the legacy applications to accommodate the same I realized I was not resisting the suggested changes at the application level with words like “why has this to be in my application”, “my team does not have the bandwidth to accommodate this change” etc.

Now this was a major shift, as a PM I would insist on keeping customizations in the applications I manage to a minimum when I had to work on interfacing with a third party application i.e. TPA and would argue endlessly on not wanting to tinker with the delivered records and pages and here I was suggesting changes in a delivered page to display data being published by a TPA, wow , my earlier reluctance to customize, expose my application to TPA was replaced by a willingness to understand the user’s needs and design a solution that would seamlessly enable data to progress logically from its point of generation to the intended power user and end user pages….

Was I surprised, yes, did I like it, yes again and did it change the way I looked at a requirements gathering session, absolutely…

You see I realized earlier I would restrict my perspective to the applications I managed as a PM, how this change would impact the existing release schedules and would critically examine if this change would add any value to the application at its core, as a PM I was doing what I should but I was not looking at the big picture of a cross functional implementation, I was not thinking of what the client needs, I was not helping the client convert his vision into a tangible application.

There dear reader I experienced the liberation that a change in perspective brings, my thinking shattered across the margins I had drawn for it. In short I had underwent a paradigm shift as Franklin Covey calls it in his amazing book “the 7 habits of highly effective people”.

Now with my BA hat I look at a situation in its grander scheme of things, I put the client needs above my habit to look at how this adds value to my application, I focus on converting the client’s requirement to a scalable, easy to use and manage application, I think of all the data points regardless of the application they lie in rather than my application and its interfaces.

THAT was my Eureka moment….