Home
About Us
Advertise
Printable version
Writing the right requirements — Part III
By Eric Riz
January 17, 2012 —
(Page 1 of 2)
This is the third and final article in my series on “Writing the Right Requirements.” (Read
Part I
and
Part II
if you haven't done so already.) If you have been reading this series, you have learned about engaging the business unit, defining a user community, and creating a phased approach to your SharePoint project requirements. Thank you to those who have reached out and provided feedback on their thoughts and successes; I look forward to receiving more notes and meeting some of you at SPTechCon.
This article focuses on strategies toward effectively creating and documenting your requirements into meaningful, tangible, actionable statements. Note that I have written this from the perspective of deploying portal functionality to the business first.
A common practice in requirements sessions is to get the team together and to simply talk through how your existing portal or intranet operates, while an analyst sits in the corner and furiously attempts to capture the information. Though this approach is unstructured and takes a strong project manager to control the session, it can uncover some valuable information on the high-level needs you’ll want to build into SharePoint. The difficult part will be documenting the information in a format to appropriately leverage the information and have it be useful in the overall process.
In order to have meaningful and result-driven requirements sessions, follow these steps to success:
Plan
: The adage “measure twice, cut once” is relevant when planning and executing requirements sessions. Spend time measuring the needs of business users and the strategic objectives the business wants SharePoint to provide. Create a schedule that shows when and where participants should meet, the details of the meeting, and the anticipated outcome for each session; also, be sure to invite participants well in advance to ensure their availability.
Finally, when planning your meeting, set each session up for no more than two hours. Enforcing the two-hour rule ensures that participants are fresh and remain interested in the conversation.
Discuss
: Start the session by outlining your objectives and expectations to the group. Show some sample portals that have been developed in SharePoint (e-mail me for screenshots) to build excitement for what you’re about to undertake. Discuss the importance of having transparency in your communication, and that each point is a steppingstone toward a formidable SharePoint solution. Then begin by asking some high-level questions to generate thought and feedback. How will the portal change the day-to-day work completed by staff? How can you best leverage portal functionality to empower users?
Next Page
Related Search Term(s):
requirements
Pages
1
2
Share this link:
https://sptechweb.com/link/36272
Related Articles
Writing the right requirements — Part II
In this installment, Eric Riz explains how to get the most input from everyone involved in the SharePoint deployment
Writing the right requirements — Part I
In order to define the right requirements, one must first obtain the proper frame of reference from team members
Add comment
Name*
Email*
Country
United States
Canada
Afghanistan
Albania
Algeria
American Samoa
Andorra
Angola
Anguilla
Antarctica
Antigua & Barbuda
Antilles, Netherlands
Arabia, Saudi
Argentina
Armenia
Aruba
Australia
Austria
Azerbaijan
Bahamas, The
Bahrain
Bangladesh
Barbados
Belarus
Belgium
Belize
Benin
Bermuda
Bhutan
Bolivia
Bosnia and Herzegovina
Botswana
Brazil
British Virgin Islands
Brunei Darussalam
Bulgaria
Burkina Faso
Burundi
Cambodia
Cameroon
Cape Verde
Cayman Islands
Central African Republic
Chad
Chile
China
Christmas Island
Cocos (Keeling) Islands
Colombia
Comoros
Congo
Cook Islands
Costa Rica
Cote D'Ivoire
Croatia
Cuba
Cyprus
Czech Republic
Denmark
Djibouti
Dominica
Dominican Republic
East Timor (Timor-Leste)
Egypt
El Salvador
Equatorial Guinea
Eritrea
Estonia
Ethiopia
Falkland Islands (Malvinas)
Faroe Islands
Fiji
Finland
France
French Guiana
French Polynesia
Gabon
Gambia, the
Georgia
Germany
Ghana
Gibraltar
Greece
Greenland
Grenada
Guadeloupe
Guam
Guatemala
Guinea
Guinea-Bissau
Guinea, Equatorial
Guyana
Haiti
Holland (see Netherlands)
Honduras
Hong Kong, (China)
Hungary
Iceland
India
Indonesia
Iran, Islamic Republic of
Iraq
Ireland
Israel
Italy
Jamaica
Japan
Jordan
Kazakhstan
Kenya
Kiribati
Korea (North)
Korea (South)
Kuwait
Kyrgyzstan
Laos
Latvia
Lebanon
Lesotho
Liberia
Libyan Arab Jamahiriya
Liechtenstein
Lithuania
Luxembourg
Macao, (China)
Macedonia, TFYR
Madagascar
Malawi
Malaysia
Maldives
Mali
Malta
Marshall Islands
Martinique
Mauritania
Mauritius
Mayotte
Mexico
Micronesia, Federated States of
Moldova, Republic of
Monaco
Mongolia
Montenegro
Montserrat
Morocco
Mozambique
Myanmar (ex-Burma)
Namibia
Nauru
Nepal
Netherlands
Netherlands Antilles
New Caledonia
New Zealand
Nicaragua
Niger
Nigeria
Niue
Norfolk Island
Northern Mariana Islands
Norway
Oman
Pakistan
Palau
Palestinian Territory
Panama
Papua New Guinea
Paraguay
Peru
Philippines
Poland
Portugal
Puerto Rico
Qatar
Reunion
Romania
Russia (Russian Federation)
Rwanda
Saint Helena
Saint Kitts and Nevis
Saint Lucia
Saint Pierre and Miquelon
Saint Vincent and the Grenadines
Samoa
San Marino
Sao Tome and Principe
Saudi Arabia
Senegal
Serbia & Montenegro
Seychelles
Sierra Leone
Singapore
Slovakia
Slovenia
Solomon Islands
Somalia
South Africa
Spain
Sri Lanka (ex-Ceilan)
Sudan
Suriname
Swaziland
Sweden
Switzerland
Syrian Arab Republic
Taiwan
Tajikistan
Tanzania, United Republic of
Thailand
Timor-Leste (East Timor)
Togo
Tokelau
Tonga
Trinidad & Tobago
Tunisia
Turkey
Turkmenistan
Turks and Caicos Islands
Tuvalu
Uganda
Ukraine
United Arab Emirates
United Kingdom
Uruguay
Uzbekistan
Vanuatu
Vatican City State (Holy See)
Venezuela
VietNam
Virgin Islands, British
Virgin Islands, U.S.
Wallis and Futuna
Western Sahara
Yemen
Zambia
Zanzibar
Zimbabwe
[Not specified]
Compose