This is the second of three in a series on writing the right requirements (read Part I and Part III, too), written exclusively for SPTechWeb and the SPTechRerport newsletter, and ahead of my requirements workshop at SPTechCon in February. I hope that the first article assisted project managers out there with suggestions on how to engage the business unit, define a user community and create a phased approach to your SharePoint project. Thanks to those who reached out and provided feedback on their thoughts and successes; I look forward to receiving more notes from readers.
This article is focused on the process behind eliciting and prioritizing requirements, and the third will suggest how to document and action your requirements into meaningful, tangible, actionable statements that your developers can begin working on immediately.
When working with your team on eliciting and prioritizing requirements, your first task is creating a measurable baseline and common understanding of the goals and expectations for your requirements. Without this common framework and measurement, you and your team are destined for failure.
Think of this as the equivalent to preparing for a trip. Before leaving home, you would have your initial requirements in hand: the duration of your trip, the weather at your destination, your planned activities while away, and what clothes you’ll need to pack. These are your variable requirements, those which you have no control over and have external dependencies (you can pack all you’d like, but the airline can still lose your luggage).
Next, you would confirm that your fixed requirements are in place; these are things that you would have a difficult time replacing while away, such as cash, medication, glasses or contact lenses. The point is, what takes priority on your list and what makes one item more important than another? This is the question your team needs to ask to be efficient and effective when writing requirements.
#!
My recommendation for requirements creation is to start with the most common component within SharePoint, the portal. The SharePoint portal is the foundation of almost every deployment, as it provides and fosters a starting point or login page for all departments. From my experience, it is the most understood concept within the SharePoint world, as most users appreciate what an intranet is, and it’s more than likely that your portal will replace some type of internal system.
To create your baseline, study and understand the component you are deploying first—in this case, the portal. Then reach out to your business units and secure representation from each in order to have an initial meeting and set some objectives.
When you begin creating your baseline and common framework, it is critical to appreciate the different focuses and views that each of your business unit representatives has. You have now amassed a team that looks at the SharePoint world through a very different lens than you do. Your finance team will have different interests and anticipated outputs to you or the human resource team. Furthermore, you will not be aware of the experiences that each has encountered in the past. For example, John may have been an intricate part of another SharePoint rollout with another firm.
Begin by drawing from various experiences and requirements focuses (who, what, when, where, why and how) as well as the different points of view your participants have. Explain what the end goal is and what your goals are for the project. Elicit feedback from your participants and embrace the conversation and experiences of your team. Explain and work through some concepts, and explore how simple business tasks get done in common ways. How do people view information, have work assigned to them, and report statuses?
Once these processes are mapped out, you can create some use cases to depict the commonalities and display them to your business units as such. It’s important that these are seen as common to the business to gain acceptance and create a unified approach to your requirements-gathering.
Next, set the objective and define the level of detail you expect from your requirements. It is important to communicate your strategy and set your scope level using an iterative approach; this takes your scope-level or high-level requirements down to detailed-level requirements. I recommend using a top-down horizontal strategy, which involves working together to deliver a set of models at roughly the same level of precision, checking their quality, and then moving down to the next level of detail. This method can accelerate the group’s mutual understanding of the requirements and reduce rework going forward.
Finally, prioritize your deliverables and engage your business units in order to predict exactly how long it will take to deliver each piece of functionality. Your success in this phase will be measured by how well your requirements have been created and whether or not your users are engaged in the process. Remember, without engagement, you will fail.
Eric
