MOSS 2007 Requirements Gathering: Fast and Focused

Since Microsoft Office SharePoint Server is a mature platform for collaboration, content management and portals, companies can implement the package without much planning or even requirements gathering. Too often, the IT department is assigned the task of technically implementing SharePoint, with little context for its use or its potential value to the organization. The individuals in Business Units or Departments, who will use the system, are kept in the dark about the plans and the functionality of SharePoint. Once IT is satisfied that MOSS is technically stable, it rolls the package out to users with little training or follow-up. This approach rarely succeeds.

In this post, I want to examine how to set the foundation for a successful SharePoint implementation by starting with a clear understanding of user requirements and the business results stakeholders want to achieve. Governance, Site construction, etc. can wait until there is a base level of understanding of the business objectives and user requirements.

Problem Statement

Requirements analysis is a standard process step in the software development lifecycle. Usually, developers, who are assigned requirements gathering, are unfamiliar with what actual users need from applications. Various methods have evolved over time to extract system and user requirements from business people. Historically, this has involved a slow process of interviews to discover the user’s real business needs. Hard working developers struggle to craft requirements from their interviews, but lack the understanding or a common vocabulary to ensure that they capture the user’s real needs. To futher complicate matters, most MOSS 2007 functionality is preconfigured. The most important requirements involve the ways that information is organized and presented based on user tasks: information architecture, content types, metadata, search configuration, and site navigation. SharePoint has many “out of the box” extensions to meet these common user requirements. Unfortunately, for developers, this means MOSS 2007 needs configuration rather than development.


Two software development methods that can be used simultaneously to make requirements analysis more effective are Agile and Lean. Agile software development methods seek to overcome the lack of actionable requirements by involving users directly in the development process, getting feedback immediately and making sure there is a constant conversation with users. Agile methods seek to quickly deliver functionality to users from which they can get immediate feedback. Lean is focused on eliminating rework and failures that can result from miscommunication between users and developers. Together these methods can be used to involve users, accelerate the project and eliminate wasted effort.


The following diagram presents an example of a requirements gathering process that is fast and focused. It involves users and quickly iterates toward confirming and testing requirements (rather than leaving testing to the last step):

process diagram 1
process diagram 2

Here are some insights learned from using this process:

· Educate real business users on MOSS functionality; discuss their role in the project.

· Check back with users as often as possible, your understanding of their requirements will only improve.

· Time box collaborative work sessions and interviews, too much time enables users to specify too many non-value added requirements.

· Publish requirements in a Wiki and encourage user review and editing.

· During the design phase, make low fidelity sketches of your understanding of the system and user requirements, encourage users to make sketches to improve the model. Talk about your questions with users and strive for clarity.

· Before coding, if feasible, conduct a conference room pilot in which the application and business processes are simulated on a table. Users can see the potential pages, the workflow, and logic of the system and can make changes before any code is written.

This process can result in a deep understanding of user requirements and the business problem to be solved. After this, the MOSS implementation team can begin to implement SharePoint using Agile techniques that encourage fast turnaround of useable functionality.

3 Responses

  1. The feedback loop and user interaction can’t be overemphasized in my opinion. Clearly, the functionality of MOSS is more than sufficient for most user groups, with many of its more sophisticated features left untouched. As the project manager for the roll out of SharePoint at a global consulting firm in a previous life, I can attest to that from personal experience.

    So it’s not the technical capabilities of a SharePoint implementation that concerns me for organizations. As you point out, rapid feedback and visualization of the end product are crucial to the success of any collaboration application. That’s the change management piece that is often lacking.

    By involving the users in the design—IT truly being consultative about their needs—MOSS and other collaborative tools can extend the ability of a group to share well beyond either their physical or normative boundaries. That is, it’s easy to see how MOSS can span time and space; but it can also help break down function, departmental, business unit, or professional boundaries as well.

    The key is still in understanding the “what’s in it for me” for the groups to implement any collaborative technology—back to the user feedback. The combination of agile and lean does offer a way to effectively “get it right the first time.” Luckily, today the IT department is better positioned to be technology consultants than ever before. That also means as users, we’re lucky as well.

  2. One thing to remember is that MOSS is somewhat similar to an application like SAP in that while it is very configurable, its real capabilities are much more vast than the modules they provide in their out-of-the-box solutions. Therefore, like SAP, developer skills are critical. And I don’t mean just technical skills. When developing in SharePoint, I have seen many sites that are underutilized and under-perform because the developer(s) were given with poor direction.

    Good business analysts that “own” their site from beginning to end, as well as on-going, are a critical ingredient — especially in the on-going maintenance and growth of the site. Pair the business analyst/site owner with a savvy developer (who is more than a configurer) and you will begin to draw the most out of what MOSS has to offer. SharePoint sites, like many other applications, do not necessarily reach their full utility until several iterations of user feedback, which result in changes & tweaks to fit the community needs. A good business analyst will either observe user patterns or seek feedback to constantly improve their site. But this also requires that he/she is working with a developer that can address more complex needs, instead of one that will push back due to lack of knowledge of the intricacies of MOSS.

    SharePoint is a collaborative tool, but is also a document repository, high quality designer website and skills manager as well. In reality is a complete web-based collaborative platform that a whole corporate intranet and extranet can be built on.

    In most companies casual users and unskilled developers have a tendency to “whip up” dozens of SharePoint sites that are often flat sites that have decent graphics, but concentrate on the document repository features (often using folders that emulate their hard drive) along with an area for discussions. A poor developer will under-utilize the capabilities of MOSS by pushing back on the site owner. Likewise poor business analyst will tend to underestimate the power of MOSS.

    Good examples of MOSS sites that begin to harness its capabilities are

    These utilize a lot of the great features of MOSS. Good examples of more collaborative sites developed in MOSS are:

  3. With such a competent platform as MOSS 2007 it is close to being naïve to believe that it would be possible to run one project to get a good system.

    In my mind MOSS 2007 is a transformation vehicle. This means that you can help the organization to change by providing new functionality, but the organization needs time to adapt and given the strong bottom up possibilities, new requirements and ways of working will appear that you did not imagine at the beginning. Therefore it is important to foresee and budget for a continuous and adaptive – and user centric – development for quite a period of time. This way the organization can adapt and evolve as it learns and transforms.

    My experience is that building a set of services that run on a MOSS 2007platform is much more powerful than building an application on MOSS 2007. For example, I would recommend building a project area service, a team service and a community of practice service parallel to eachother, rather than building one “Collaboration application” capable of handling projects, teams and communities.

    Building a platform on which you put different services is a bit more demanding from a governance point of view because you need one role for aggregating the requirements for a particular service, another role for aggregating the requirements for the platform from many services. Many organizations, not to mention IT departments, still have a firm belief in one need – one application, but that does not utilize the power of MOSS.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: