As the title states, I’m at the SharePoint Tech Conference in San Francisco. Not quite all the same type of people that we saw at CodeMash and lots of SP Admins throwing playful darts at the Developers that are here.
Yesterday I sat through “Writing the Right Requirements”. I chose this session because it is always a challenge to define what our clients need versus what they want. Now, we also have the challenge of “I want to use SharePoint “ before understanding what they want SharePoint to do!!!
So, what were my take aways?
1. Changing our thinking behavior:
a. Normal/Traditional order of questions:
When –> Where –> What –> Why –> Who –> How
b. When Requirement Gathering:Why –> What –> Where –> How –> Who –> When
2. Further Definitions
a. Why? maps to Mission, Vision and Objective Statements
b. What? and When? maps to New Capabilities, Strategies and Goals
c. How? Who? and When? maps to Competencies, Business Process and Project Management
3. Use the BUS – Business, User, System – principle for each requirement. This relates to our behavior driven requirements.
4. Information should be available to the user within 3 clicks or less. I think we try to do this.
5. Always rename SharePoint sites to anything besides “SharePoint”. – gives the user the ownership of the functionality – not SharePoint
6. Make sure you have definitive goals for each project
7. The average Word user uses 5% of the functionality available in Word.
At the end of the session, I didn’t come away with any light bulb moments on how to gather SharePoint requirements differently than what we currently do. I found the speaker’s blog entries on writing requirements (http://www.sptechweb.com/Write_the_right_requirements/By_By_Eric_Riz/36132) more informative. This session was more reminders that we (IBS) are doing things that are working for Concatenate (the company where the speaker works).