Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Become Your Own Business Analyst, Gather Requirements for Any Project

1,905 views

Published on

Published in: Technology, Education

Become Your Own Business Analyst, Gather Requirements for Any Project

  1. 1. Become Your Own Business Analyst, Gather Requirements for Any Project Cathy Dew
  2. 2. Speaker Bio Cathy Dew  Consultant at Planet Technologies  Graphic Designer, Consultant and SharePoint MVP  Over 6 years of SharePoint branding experience  Author: SharePoint 2010: Six in One  catpaint1 on Twitter  www.sharepointcat.com
  3. 3. Agenda  Ask the Questions  Analyze the Responses  Develop a Plan  Map Requirements to a Project
  4. 4. Ask the Questions  Depending on the Project Type the Questions Differ  Avoid Technical Terms  Learn about the Business not just the problem  Adjust your questions to use the terminology of the business
  5. 5. Sample of Switching Questions  Original  Question: Do you often share work documents with people outside of your department?  Modified Question because department is not valid in the company  Do you often share work documents with people outside of your immediate work group?
  6. 6. Styles of Questions  Many     ways to ask questions Interviews White boarding Surveys Game storming
  7. 7. Cater to Your Audience  Stakeholders  Technical  End Users
  8. 8. Group vs Individual  Groups are great to understand the business and relationships  Individuals are great for details and understanding a specific process from one perspective  *Groups can be a challenge to do remotely and if there is contention/disagreements
  9. 9. Order isn’t Important  The goal is to keep the conversation flowing  While we typically order questions by topic, its best to encourage open conversation and go with it.
  10. 10. Start Simple  Learn about the person and how they work first.
  11. 11. Be friendly  Don’t   put them on guard Make sure it is known you aren’t there to judge Start out by saying it is a judgment free zone so be honest in how you actually do things.
  12. 12. Personal Tips to Interviews  Watch  body language Are they guarded and you can tell they won’t share real information  If it feels like you are pulling teeth, switch topics and find another one to get them to talk  Its okay to tell them you don’t know if asked a question that you really don’t know.  Tell them you will ask someone and get back to them
  13. 13. Who to meet with?  It is great to meet with managers as well as employees, but be careful to not put managers in interviews with their staff
  14. 14. Starter Questions  What is the first thing you did when you got to work today?   Is What kind of emails were you looking for? there something you know you have to finish before you leave today?
  15. 15. Top 10 Questions for Governance  10.   9.  How Big is too Big? Controlling the growth and size of your sites with quotas will allow you to proactively manage the size of your databases, ensuring that you remain within supported size limits and that data is recoverable in a timely manner. How did that screwy file get there? Creating a list of acceptable file types will help you to control not only acceptable content but also help to control site size. Also look at virus protection and what you want on your servers
  16. 16. Top 10 Questions for Governance  8. How Many is too Many?  Find out how many versions of documents people use and need for their libraries. Decide how you want to manage versions. Also look towards large lists and how you will handle large item counts to avoid non-supported lists.  7. Where Did that Go and How Do I get it Back?  Planning your Disaster Recovery and Backup strategy is an important part of any SharePoint implementation. Determine how long you can wait and what content you are willing to potentially lose to help guide you in this strategy.
  17. 17. Top 10 Questions for Governance  6.   5.  When is a Site not a Site? You should determine what decision points are needed to create sites in your environment. How Do I Make it Not Look Like That? Determine what level of branding you would like to use and how it should be applied. Take into account new site creation behavior as well as site templates.
  18. 18. Top 10 Questions for Governance  4.   3.  When is it too Personal? Then you can talk about how to manage what properties are shown to whom and what kind of information goes in them. – User Profiles Would You Like Fries with That? Adding customizations to your site can be tricky from a management perspective. Whether these are third party tools or custom development to determine how you validate these solutions and implement them for use.
  19. 19. Top 10 Questions for Governance  2. How do I act Like the Wizard Behind the Curtain?   1.  Determining if you want to manage user permission in a centralized or decentralized structure is important and can help encourage end user adoption Can I Teach an Old User New Tricks? The ultimate goal of any governance plan should be to not hinder End Users actually using the environment. Make sure you take into account how your End Users Need to work and incorporate that into your plan.
  20. 20. Analyze the Answers  This is the biggest challenge  Taking conversations and mapping them to technical requirements  Example: I work with an excel spreadsheet that only I need to edit, but multiple people need to see, and they are always messing up with their filtering. Req: Use of Excel Services to display spreadsheet information to multiple people, while restricting editing to only a few. 
  21. 21. Analyze  Best to document and start to map these requirements in multiple types.  You will find the following types of requirements coming out of the gathering process:  Business  Technical  Compliance
  22. 22. Report Issues or Concerns  Many times one of the most important things you can capture are the items that can’t be done by SharePoint alone    Custom Development Not something that the product supports Issues with lack of training for team
  23. 23. Validate before Planning  Once you have mapped out the requirements based on analysis you will need to verify them  People to verify with:    Architect (your company or customer) Developer (if needed) Stakeholders
  24. 24. Why Validate?  This will help to either reinforce what is needed or eliminate extra requirements before you develop the plan of action
  25. 25. Develop a Plan  Write up the Project Proposal and show where the requirements are covered  Somehow map them to the documents where you analyzed… either by number, scope or some other method
  26. 26. Requirement Creep  Don’t forget that requirement creep is what we are trying to get away from, but will always happen to some extent.  The more you gather, analyze and present the easier it is to avoid this  But don’t get stuck in constant requirement gathering only cycle
  27. 27. Thank you for attending! Cathy Dew, MVP @catpaint1 www.sharepointcat.com

×