Work-Integrated Learning Community Support and Research Portal
Since April 2015, I have been leading the creation of the Work-Integrated Learning Community Support and Research Portal (WIL Research Portal), a project brought to IST by the Waterloo Centre for the Advancement of Co-operative Education (WatCACE). In line with their mandate to increase understanding of co-operative education through innovative research design, this website is intended as a resource for researchers the world over who study work-integrated learning, making all core scholarship available through a single search interface, and providing a forum for people to connect and share ideas.
As presented at a recent Professional Development Seminar, there were three unusual aspects to how this project was run that helped the WIL Research Portal come to fruition: the way that requirements were determined, the proactive creation of an information model, and the employment of co-op students as developers. Each of these factors could be implemented in other IT projects – or indeed in any project – to reap similar benefits to those we encountered.
In a three-part series of blog posts, I will outline what each of these activities entails and what value they bring to a project. This initial post will examine the nature of a needs assessment and how it differs from common project management practices.
Assessing user needs
Determining requirements is an intrinsic part of any project, vital to establishing scope and defining objectives, but as the blog post “Scope Management vs. Requirements Management” discusses, understanding and conveying what the requirements are is no easy feat. Stakeholders may have trouble assessing the problem space objectively, translating concerns into requirements, or communicating those requirements to a project manager. For technology projects these issues are particularly pressing because clients may not know what is possible or what terms to use to express what they want.
To counteract this reality, we therefore took an approach I am calling a skeptical needs assessment. ‘Needs assessment’ because the focus was on establishing the needs of the clients and end users, while translating those needs into the specific requirements of the project was set aside until the problems were clearly understood. ‘Skeptical’ because nothing was taken to be true without confirming that it was based on a well-informed understanding (i.e. alternatives and options had been presented to the clients) and that all parties had the same understanding of ideas. Both parts of this represent a change from the typical modus operandi of technology projects on campus (and in general), whether because clients arrive with a solution already in mind, or because time constraints push things through the design phase too quickly.
Requirements gathering vs. needs assessments
The difference between a needs assessment and requirements gathering is in both the line of questioning and the ways in which it is asked. Rather than focusing on functionality and the precise steps performed, determining needs is about understanding the problem space. What needs to be accomplished? What people, documents and tools are involved in the work? What are the good and bad parts of the current setup from each person’s perspective? How does this area relate to other activities on campus? In essence, the emphasis is on user experience and inputs/outputs, not on the minutia of process or tool design.
Answering these questions effectively requires a whole toolbox of techniques, with different methods employed in different situations. The design firm IDEO has put together a catalogue of 51 different approaches conveyed through a novel deck of cards (sets of which are available for loan from the Enterprise Architecture group). The section “Choosing UX Tools & Techniques” from a chapter in the book Smashing UX Design: Foundations for Designing Online User Experiences also does a good job of describing appropriate use cases for various methods. While there is no set formula, in general I would advocate for interview or contextual research techniques, which put you one-on-one in the user’s space, over focus groups where participants are likely to hold back for fear of offending others in the room, or surveys where the context of responses is lost and assumptions are by necessity baked into the questions.
Regardless of the method used, though, one universally applicable point is that end users should be consulted – not in a token ‘here is one person to represent a diverse mass’ type of way, but as far as is possible through a representative sample of each of the different user groups.
From the moment a project proposal comes in and throughout the needs assessment process, the other part of the equation is treating information with a healthy amount of skepticism. ‘Realism’ would perhaps be a better term to use – being realistic that people don’t like change, never see themselves as the problem, and don’t have time to read extensive documentation – but skepticism is a way to handle these realities.
While a client may have done extensive research to select a tool or to define their needs, they may not have the skills or the perspective to understand their business independent of their current technology. Confirming that all of the ideas and decisions are rational and well informed is one of the most important services that modern IT personnel can provide. Contrary to historic conceptions of customer service, however, this requires abandoning the notion that ‘the customer is always right’ for a more pragmatic ‘the customer knows the desired destination’, and embracing that figuring out the best way to get to that destination is your job. Done poorly, this is the origin of the stereotype of the know-it-all developer, but done properly it is about delivering an end product with which they are truly satisfied, while increasing their understanding of their business and technology along the way.
There are two key values to a thorough and accurate needs assessment. First, during the project this background information helps control scope creep. As part of the process more alternatives will be discussed, limiting the number of late game additions that can be requested, and even if they do arise it is far easier to discount them as ‘nice to haves’ with a clear cut statement of needs to fall back on.
Second (and perhaps more importantly), not long after the project closes, when the shine starts to come off of a new application, it will become clear whether the changes actually addressed any of the underlying problems or whether they were cosmetic adjustments. A needs assessment helps ensure that the former is the case, and that clients and users alike will be happy with the result for years to come.
Check back Thursday for part two of the series, which explores "information modeling".