Skip to Content

Using wikis to Gather Requirements

The latest Forrester TechRadar report was released this earlier this month and identified “good evidence” wikis are transforming collaboration in the enterprise.  It said:

One of the more promising of the Web 2.0 technologies for the enterprise, wikis show good evidence of helping transform collaboration in the enterprise. Users report success with many wiki endeavors when they’re sponsored by business leaders and connected to business processes.

Wikis can play a substantial part in managing and documenting SAP implementations and processes. They can be used in conjunction with ASAP or PRINCE2 type methodologies in order to improve collaboration between geographically and functionally disparate groups. One aspect of an SAP project that can be improved using wikis is the requirements gathering and definition process.


Collaboration 1.0

A recent guest post on Stewart Mader’s Grow Your Wiki blog identified the traditional process teams follow when gathering project requirements. The process identified below will be familiar to many consultants as it’s representative of the tools many organizations currently use to collaborate:

1. Someone on the team develops a template in Microsoft Word or Excel
2. They post it somewhere or email it out to the team
3. Each requirement document becomes a separate file that the team sends around via email to complete
4. The requirements eventually get done, but not without a significant waste of time and level of frustration

Jason Rothbart of Groupswim outlined the process above as being both costly and inefficient. The technology used to drive such a process is based on technologies, which are more than 15 years old and ill-catered for mass collaboration. Version control is not easily maintained and there is no live version of the document, always available, with a single version of the truth. Organizational inertia, however, allows such a process to flourish as it does not require any new learning on the part of the participants, or any new technology to be implemented.


Collaboration 2.0

A more efficient approach for requirements gathering will be obvious to anyone who has used a wiki. A wiki is great tool for group collaboration as its versioning features allow all edits to be easily tracked and reverted if necessary. The benefits of using a wiki to gather requirements are outlined in Wikis at work defining requirements in a new way as:

1. It is easy to develop a living template that can change dynamically as the team learns on the project
2. Version control goes away, because each document only has 1 copy that everyone uses and shares
3. There are no software issues because everything is done using a browser
4. All versions are saved so it is easy to revert back if necessary
5. Documents are fully searchable and you can track who contributed and what specific changes they made

Using a wiki makes group collaboration efficient and transparent. It provides for greater group interaction and allows documents to ‘live’, because they’re easy to edit and update. Allowing users such openness and accessibility to live documents during the requirements gathering process can lead to much greater trust and responsiveness from those participating. It can also ensure greater focus during the realisation phase, as requirements are clearly visible and accessible to all, throughout all project phases.


Wikify documents to allow them to live

If functional specifications or requirements have been documented in Word files during the Blueprint phase, it’s a good idea to try to wikify these during realization. This will allow for much more visibility of requirements, and will also allow and control any changes that may need to be made. It will also allow test scripts, bugs, training documentation etc. to be linked back to initial requirements, and the associated blueprint. This can allow for the requirements lifecycle of design, build and golive to be fully tracked and audited.

What about methodologies

Using a wiki during the Blueprinting phase of a project does not impede the standard ASAP or PRINCE2 methodologies. A wiki changes ‘how’ people collaborate and work together. It does not affect or change the end results of these interactions. Wikis can be thought of as technology enablers, that facilitate a means to an end. The milestones and objectives during the Project Preparation, Blueprint, Realization and Go-live phases will remain the same. A wiki, however, provides a platform to link these outputs to ensure they provide for a cohesive and transparent project narrative.

SAP’s wiki future

SAP’s communities, including SDN, BPX and Collaboration workspace contain wiki functionality to allow members to work together and collaborate on different topics. The wiki concept is enthusiastically promoted by the community evangelists as a means of focusing members on the creation of valuable content for others. docupediA – SAP NetWeaver’s interactive documentation is using a wiki to allow the community to enhance, rate and comment on SAP help documentation. Wiki functionality is also being News from SAP NetWeaver Portal: Wikis Included in Product Offering into the SAP NetWeaver Portal from Q4 2009.

Forrester expects the market for wikis and other Enterprise 2.0 technologies to expand significantly over the coming years. The expansion of wikis into enterprises with the SAP NetWeaver Portal has the potential to expose many more business users to this new method of working. While SAP projects can change what people do (e.g. the processes they adhere to), wikis can change how people do things. If both these aspects of change can be incorporated into SAP projects then they truly have the potential to change the fabric and culture of organizations.

You must be Logged on to comment or reply to a post.
  • I think this is a great idea.  I’m continually disgusted, particularly in the area of off-shoring solution development, with trying to build up solutions in MS Word.  It’s ridiculous…  and these documents start to take on a ‘contract’ tone.
    • Documents need to ‘live’ throughout a project; their usefulness should not end once the project phase has been completed. Having information on a wiki allows it to be easily edited and updated thoughout a project. Modifying Word documents requires updating versions, tracking changes, emailing the latest versions etc. Within a wiki, the software handles all of this, and as such it’s a more productive medium for living documents.