Digital White Papers

USING DESIGN TO IMPROVE KM WHAT ARE WE DOING WRONG? This is a typical process for system development within our firms: CASE STUDY idea! plan requirements design develop user acceptance testing launch update plan Here's more detail about that traditional model: Lawyers come to KM with their ideas, problems and needs. We work with the lawyers using a range of techniques to understand their requirements, have initial discussions with the technology team and come up with potential solutions. We then develop business cases and navigate through our various approval processes. Once a project is approved, our technology colleagues ask for our requirements and — like the lawyers many of us are — we write … and write … and write. We excel at drafting lengthy requirements documents that describe the fields and functionality of the solution we believe is possible based on what we know technology can do. We hand over that wordy document to the technology team and start having meetings to discuss development ideas and respond to questions. Often the development ideas are abstract, and the answers to many questions are already in the requirements document. Development begins without a common understanding, which sometimes means parts of the project will be reworked far into the development stage. This is a frustrating experience for both KM and IT, and it slows down the development and completion of projects. We've spent years using the traditional industry methodology for developing and communicating KM project requirements to IT, but it is not working. Functional and technical requirements often come at the expense of user needs and experience requirements. The design and development process should be a dialogue about our end users — about fulfilling their needs and solving their problems, and not about listing what the technology should do. STIKEMAN ELLIOTT Read how Stikeman Elliott LLP changed their process. IN SEARCH OF A BETTER WAY There are many different approaches to system and solution development. It was a chance conversation with Kate Simpson of Tangledom that set us on our path to an improved design process. She described a session where KM and IT were both in the room and drawing everything out on the walls. A light bulb went off. We realized we needed a new approach to developing our requirements if the problems, ideas and needs of our lawyers were going to be heard and understood. We needed to create requirements that communicated accurately what our users wanted to achieve with the system, what they wanted the system to do and how they wanted to interact with it, but in a way that resonated with our technology team rather than the KM team.

• Cover