I admit it. I'm addicted. I just could not imagine working without it. Sometimes I get into a cold sweat when it's down. I think about it alot. I've seen it grow and develop. I've nurtured it. And I could not conceivably work without it. Really. What am I talking about? Well, it's the project wiki that I, along with colleagues in the UK and India, have been working on for the past 9 months.
I've used a wiki on my last two projects, and have become a evangelist and advocate of the platform for SAP projects. As I am finishing my current project I've come to the conclusion that I could not progress efficiently through another project without using this type of platform. It's ease of use and flexibility represent a breath of fresh air when compared with email and traditional document formats.
What we use it for
There are many diverse ways to utilise the collaborative features of a wiki. On our SAP BI project we have been using it primarily as a means of:
Onboarding - We have a few pages that contain all the information necessary for a new team member to join the project. This includes:
- details of everyone in the team including their roles and previous experience. Each project team member has their own profile page which can contain links to their Linkedin or SDN profiles. As much as possible we have requested that people upload photos of themselves or even their office environments. This allows colleagues to create more trusting relationships and consequently creates a more productive working environment.
- administrative details such as project locations and the locations of our offshore colleagues are included within wiki ( see google mashup). Details of printers, how to access the SAP GUI, SAP landscapes (e.g. saplogon.ini, SRM/Portal URLs, documentation repository details, contact lists etc) and system landscapes are also documented.
- outlining the rational for the project. The reasons behind the project and what it is trying to achieve are explained e.g. cost savings, adherance to new legislation a mandate to increase sales etc. This helps new joins to quickly understand and contextualise the project without having to search through reams of old documents.
- the project methodology, including stages and deliverables are outlined. Ensuring all members of the team have an accurate understanding of what is expected during each project phase is critical to establishing high performing teams from the outset.
Project management - Wiki is an ideal tool, because it serves as a central hub in which we can organise everything. This includes:
- outlining tasks at the start of each week and linking these to our overall plan and timescales. There are numerous interesting timeline visualisations that can be embedded to highlight project milestones and deadlines e.g. Dipity. These can bring to life otherwise static dates on a project plan.
- using wiki to streamline workflow and reduce the reliance on email and documents. There is no need to create documents for many simple or repetitive tasks. Meeting minutes are recorded centrally on wiki, discussions takes place on talk pages instead of through email, and design decisions are recorded in on wiki. The transparency and auditability of the wiki software makes it an ideal platform for recording a narrative of project discussions and resulting decisions.
- improving communication regarding project progress. The status of tasks is updated on wiki e.g. assigned to, expected completion date etc. This means that anyone on the project can have a clear view of the status of deliverables, and whether timelines will be met. Weekly status reports are created on wiki allowing anyone - not just management teams - to analyse progress achieved and outstanding issues.
Documentation - The ease at which a wiki can be updated, its auditability and searchability makes it an ideal platform within which to create project documentation. We've used our wiki to document various aspects of our project including:
- the gathering of project requirements. These were then collated into official documents with which the client signed-off. Unfortunately, it was not possible for them to sign-off on these directly in wiki. Most wikis, however, allow for data to be easily exported in a wide variety of formats e.g. RFT or PDF. This allows for data to be easily downloaded to create official documents if required.
- aspects of the blueprint were transferred into the wiki to ensure nothing was missed and everything was built to the specifications signed off. While things changed throughout various project states it was important to always remember the central tenets of the blueprint, and design/build according to these. Ensuring that information in the original blueprint 'lived on' throughout the project was important to ensuring we adhered to business expectations.
- the design rational was recorded on wiki during the design phase. This included recording the rational for writing particular code, making enhancements and reaching specific design principles. On large projects the rational for particular decisions can often be forgotten a few months later. This is especially true if there is a high turnover of staff. Therefore it was important to have these recorded at the time decisions were made.
- testing use-case scenarios were also documented on wiki. For example, when we were designing our solution we had some very specific examples of scenarios which we needed to unit-test against. These included dozens of different document numbers and timescales in which different developments were always tested against. Storing these in a central place on wiki, and recording unit test results against these, helped us efficiently manage all our unit-test criteria and results.
- configuration and support documentation was created directly within the wiki and consequently could easily be handed over to the support teams i.e. just by providing a URL. This would allow them to easily update the documentation after go-live and provides an excellent platform for knowledge transfer. Wiki allows for videos to be embedded within pages, and as such more interactive documentation could be created.
Given our experiences over the past few months I would thoroughly recommend using a wiki for at least some aspects of SAP projects. I am not advocating replacing existing project management tools e.g. Teamforge, Basecamp etc., rather I believe a wiki enhances these. It creates a more efficient communication medium in which users can subscribe e.g. using RSS, to receive specific project updates e.g. on the project plan, weekly status reports. It also allows for a project narrative to be created, interspersed with discussions and interactive content.
Organisations are now expecting blueprint, design, testing and configuration documentation to be seemlessly linked together and accessible anywhere from a standard web browser. A wiki allows for these links to be created, thus contextualising the content and allowing for more meaningful analysis.
Transparent, Participatory and Collaborative
Earlier this year President Obama issued a Memorandum for a Transparent and Open Government. It emphasised Government should be transparent, participatory and collaborative. This is exactly what SAP projects should be, and in our experience using a project wiki goes a long way towards meeting these goals.
References:
To learn more about evaluating and using wikis see:
* 10 Tips for a Successful wiki
* News from SAP NetWeaver Portal: Wikis Included in Product Offering
