Managing SharePoint Projects Part 1 - Requirements Gathering and Analysis, talks about the art of gathering & analyzing requirements for SharePoint projects.
In this post, I share my industry experience in handling customers, gathering requirements, setting expectations right and documenting requirements, so as to do things right the first time.
1. Project Roles/Structure:
The Business Development officer/Sales rep gets the project for the organization, he knows "What SharePoint can do and how it fits in the client requirements", he bids and gets the contract for the company, then interacts with the Delivery Manager to get the project done.
The Delivery manager has many projects to deliver under his department/region umbrella, so he passes it on to the Project Manager and gives him full authority and control over the project.
The Project manager has a SharePoint team in place to implement SharePoint projects. the team structure for a medium to large project implementation ideally comprises of a SharePoint Solution Architect, SharePoint Admin/Infrastructure team, Team/Project lead, a Test lead or Testing team and finally SharePoint team members for project implementation.
Again the above team composition is Project specific, in cases of small project implementations I have seen SharePoint developers playing all the above mentioned roles under the guidance of a team lead and project manager successfully.
2. Role-Responsibility: Here is the roles-responsibilities mapping details:
3. Requirements Gathering and Analysis Participants:
Requirements Gathering & Analysis team can be formulated using the following permutations and combinations:
a. Project Manager and a Team Lead together
b. Team Lead and SharePoint Architect together
c. Team Lead and member/s of development team or
The above participants might be called as SharePoint Requirements SME(s)/Analyst(s).
For the sake of convenience, I will use the acronym RGA, which means Requirements Gathering Analyst(s) (can be an individual/group of individuals as mentioned above.)
4. Requirements Gathering and Analysis Techniques:
The common techniques of gathering and analyzing SharePoint requirements are as follows:
a. Record your Discussions: Since RGA closely interfaces with the customer all the time, he needs to discuss with the customers, either face-to-face or live meetings or video conferencing. These discussions generally start with either their existing systems which they would like to re-engineer or migrate to SharePoint or a new system to be developed from scratch.
Its always a best practice to record these discussions in the background via some audio/video recording tool, in all cases make the customer aware that you are recording the sessions and get his approval before you do so. Firstly it is an important record/proof of what has been discussed and secondly you might want to re-visit for your own benefit.
Re-visit these recordings in case you are unclear or pass it on to the other team members parallely so that they have the feel of the project.
b. Dare to Ask Questions: Never assume things when gathering requirements, ask a lot of questions, let the communication be a two way process. Sometimes, you might interrupt and ask questions as well. I ask a lot of silly questions and get customer conformance as well.
Sometimes, there is a huge difference between what the customers literally say and what they actually mean. Like they would say as if they need only a Knowledge Management solution, but in reality they actually expect a Knowledge Management portal with Multi-lingual features, Advanced workflows, Advanced Reporting scenarios and other complexities as well.
The complexity and scope of project gets clarified only when you dare to ask questions.
c. Always Summarize: After each logical end of the discussion summarize your understanding and get customer conformance. In that way, you feel confident and customer is also happy that you have understood things properly.
d. Avoid unnecessary arguments: Never argue with the customer unnecessarily, you may suggest but can't argue and put him off. That's not the objective. Remember Customer is always the king. Like it or not, but it is the ultimate truth. I have faced it a lot many times, when customer has made some sarcastic comments and I had to nod and take it in good humor.
e. Get to know the customer environment/policies: Especially with Banks & Financial Institutions, since they won't allow custom code, feature deployments, webparts etc in their SharePoint farm. Its always better to discuss this aspect in advance, as a lot of the requirements that you will discuss might need extensive customizations in SharePoint. In such a scenario, always mention it outright to your customers. There will always be a work-around process that involves communication between customers IT Infrastructure team and your team on the need to get custom dlls, features, web parts, third party tools etc. deployed in a safe and an effective manner.
f. Manage expectations: SharePoint is an over-hyped product, lots of customers have been tricked to believe that SharePoint can do everything out of the box. It is the job of RGA to set expectations right for the customer and communicate what can be done OOTB and what sections would need customization, I prefer to give them alternative options like third party tools, custom development as per the org environment policies etc and somehow try to create a Win-Win situation.
g. Wired frame diagrams/Proto-type: Its always a good practice to create wire-frame diagrams and get customer buy in. Proto-types are even more effective, but it all depends on the nature of requirements and time pressures. I prefer to make proto-types for complex projects, for lesser complex projects, Wired-frame screen diagrams would generally suffice.
h. Final Output: At the end of the day, what matters is the final output, the RGA should be effectively able to write a Business Requirements Document (BRD), Use Case Requirements Document, System Requirements Specifications document (SRS) and Requirements Tracking and Traceability (RTT) document.
i . Use Case Specifications document: Here we document the User-System interaction with appropriate Use Case diagrams, Preconditions, Post-conditions, Normal Flow and Alternative Flow.
ii. Business Requirements document (BRD): Here we document the Business Perspective/Business need. Use case ids are linked to each Business Requirement.
iii. System Requirements Specifications (SRS): System requirements is again the System requirements documented in detail, it links with the Use Case document and the BRD.
iv. Requirements Traceability Table (RTT): Its an excel sheet that maps the Business Requirements Ids with appropriate Use Case document ids and SRS ids. It will also map the Unit & System Test Case Ids for each Business Requirement ID.
In this post, I share my industry experience in handling customers, gathering requirements, setting expectations right and documenting requirements, so as to do things right the first time.
1. Project Roles/Structure:
The Business Development officer/Sales rep gets the project for the organization, he knows "What SharePoint can do and how it fits in the client requirements", he bids and gets the contract for the company, then interacts with the Delivery Manager to get the project done.
The Delivery manager has many projects to deliver under his department/region umbrella, so he passes it on to the Project Manager and gives him full authority and control over the project.
The Project manager has a SharePoint team in place to implement SharePoint projects. the team structure for a medium to large project implementation ideally comprises of a SharePoint Solution Architect, SharePoint Admin/Infrastructure team, Team/Project lead, a Test lead or Testing team and finally SharePoint team members for project implementation.
Again the above team composition is Project specific, in cases of small project implementations I have seen SharePoint developers playing all the above mentioned roles under the guidance of a team lead and project manager successfully.
2. Role-Responsibility: Here is the roles-responsibilities mapping details:
- Business Development Lead/Sales Rep - Managing Contracts, RFP's, High level bid estimates
- Delivery Lead - Responsible for Project execution, has many projects under his umbrella.
- Project Manager - Resource mobilization, Project Management activities include: Project Planning, Estimation, Risk management, Client interfacing, Co-ordination, Control and getting things done. Needs to create Business Requirements Document.
- Project/Team Lead - Gathering/understanding requirements from the client, constant customer interaction/communication for clarifications, project progress, team meetings, progress/status checks, prevent effort/schedule slippage, may also play a part in the project estimation. Needs to create Software Requirements Specification and Use Case documents along with Use Case Diagrams.
- SharePoint Solution Architect - Technical Architecture/Solution, Tools/Technology evaluation, Capacity Management, Hardware sizing, Farm scaling, High level and Detailed level technical diagrams
- SharePoint Developer - Developer is responsible for actual technical implementation, creation of deployment scripts, unit test cases, code review (for custom features, infopath forms etc.), process/product quality, they might be additionally involved in Requirements Gathering or Estimation process.
- SharePoint Admin/Infrastructure team - Responsible for SharePoint environment set-up, Configurations, Deployments, Back Up/Recovery, Disaster recovery, High Availability, Load balancing techniques like Network Load Balancing, Round Robin etc.
- Test lead/Testing team - Responsible for System and Integration testing, creation of system/integration test cases, logging Defects/Bugs, discussion with development teams w.r.t to Product performance and quality.
3. Requirements Gathering and Analysis Participants:
Requirements Gathering & Analysis team can be formulated using the following permutations and combinations:
a. Project Manager and a Team Lead together
b. Team Lead and SharePoint Architect together
c. Team Lead and member/s of development team or
The above participants might be called as SharePoint Requirements SME(s)/Analyst(s).
For the sake of convenience, I will use the acronym RGA, which means Requirements Gathering Analyst(s) (can be an individual/group of individuals as mentioned above.)
4. Requirements Gathering and Analysis Techniques:
The common techniques of gathering and analyzing SharePoint requirements are as follows:
a. Record your Discussions: Since RGA closely interfaces with the customer all the time, he needs to discuss with the customers, either face-to-face or live meetings or video conferencing. These discussions generally start with either their existing systems which they would like to re-engineer or migrate to SharePoint or a new system to be developed from scratch.
Its always a best practice to record these discussions in the background via some audio/video recording tool, in all cases make the customer aware that you are recording the sessions and get his approval before you do so. Firstly it is an important record/proof of what has been discussed and secondly you might want to re-visit for your own benefit.
Re-visit these recordings in case you are unclear or pass it on to the other team members parallely so that they have the feel of the project.
b. Dare to Ask Questions: Never assume things when gathering requirements, ask a lot of questions, let the communication be a two way process. Sometimes, you might interrupt and ask questions as well. I ask a lot of silly questions and get customer conformance as well.
Sometimes, there is a huge difference between what the customers literally say and what they actually mean. Like they would say as if they need only a Knowledge Management solution, but in reality they actually expect a Knowledge Management portal with Multi-lingual features, Advanced workflows, Advanced Reporting scenarios and other complexities as well.
The complexity and scope of project gets clarified only when you dare to ask questions.
c. Always Summarize: After each logical end of the discussion summarize your understanding and get customer conformance. In that way, you feel confident and customer is also happy that you have understood things properly.
d. Avoid unnecessary arguments: Never argue with the customer unnecessarily, you may suggest but can't argue and put him off. That's not the objective. Remember Customer is always the king. Like it or not, but it is the ultimate truth. I have faced it a lot many times, when customer has made some sarcastic comments and I had to nod and take it in good humor.
e. Get to know the customer environment/policies: Especially with Banks & Financial Institutions, since they won't allow custom code, feature deployments, webparts etc in their SharePoint farm. Its always better to discuss this aspect in advance, as a lot of the requirements that you will discuss might need extensive customizations in SharePoint. In such a scenario, always mention it outright to your customers. There will always be a work-around process that involves communication between customers IT Infrastructure team and your team on the need to get custom dlls, features, web parts, third party tools etc. deployed in a safe and an effective manner.
f. Manage expectations: SharePoint is an over-hyped product, lots of customers have been tricked to believe that SharePoint can do everything out of the box. It is the job of RGA to set expectations right for the customer and communicate what can be done OOTB and what sections would need customization, I prefer to give them alternative options like third party tools, custom development as per the org environment policies etc and somehow try to create a Win-Win situation.
g. Wired frame diagrams/Proto-type: Its always a good practice to create wire-frame diagrams and get customer buy in. Proto-types are even more effective, but it all depends on the nature of requirements and time pressures. I prefer to make proto-types for complex projects, for lesser complex projects, Wired-frame screen diagrams would generally suffice.
h. Final Output: At the end of the day, what matters is the final output, the RGA should be effectively able to write a Business Requirements Document (BRD), Use Case Requirements Document, System Requirements Specifications document (SRS) and Requirements Tracking and Traceability (RTT) document.
i . Use Case Specifications document: Here we document the User-System interaction with appropriate Use Case diagrams, Preconditions, Post-conditions, Normal Flow and Alternative Flow.
ii. Business Requirements document (BRD): Here we document the Business Perspective/Business need. Use case ids are linked to each Business Requirement.
iii. System Requirements Specifications (SRS): System requirements is again the System requirements documented in detail, it links with the Use Case document and the BRD.
iv. Requirements Traceability Table (RTT): Its an excel sheet that maps the Business Requirements Ids with appropriate Use Case document ids and SRS ids. It will also map the Unit & System Test Case Ids for each Business Requirement ID.
Comments
Post a Comment