Scenario Planning For A Successful DAM Journey

Getting to Success: A Scenario-driven Approach for Selecting, Implementing, and Deploying Digital Asset Management Systems

Usage scenarios are simple narrative descriptions of current or future state use of a system. For DAMS initiatives, scenarios are an important tool that can be used throughout all stages: selection, implementation, launch, and beyond. Scenarios are a lightweight, simple, clear, and effective method for defining the goals and intended use of a system. They help facilitate communication between stakeholders and vendors, providing a starting point for ongoing conversation that ensures all parties have equal footing in the discussion. This paper provides a definition of scenarios, describes their key features and structure, identifies their benefits, and offers recommended practice for using scenarios throughout the lifecycle of a DAM deployment process. 

This paper was originally published in the Journal of Digital Media Management, Volume 7 (2018-19). 

Introduction

Organizations embark on digital asset management selection and implementation efforts for a number of reasons: to create a centralized library of assets, to enable efficient collaboration between departments, to improve review and approval processes, to streamline multi- or omni-channel distribution, and more. In all cases, the end goal is undoubtedly the same: to successfully transform some aspect of how the organization works, and to affect meaningful and productive change that will ultimately allow the organization to better serve its mission and stakeholders.

When the need for change and the opportunity for improvement is first identified, agreed upon by the relevant stakeholders, and given the green light by senior leadership, the possibilities are exciting. But it is well known that organizational change efforts can be long and difficult. Statistics and stories abound on the high failure rate of technology projects.¹ Categorically speaking, digital asset management is no exception. Selecting the right technology is a daunting task. Implementation is yet a further hurdle. Things can get even more difficult at the launch and roll-out stages. Reaching the end goal can take years of sustained effort. This is not to say that embarking on technological change is not a good idea, or that it shouldn’t be undertaken. Rather, acknowledging the inevitable challenges, and identifying ways of mitigating them, should be an important aspect of planning.

Undoubtedly, one of the key challenges throughout digital asset management system (DAMS) selection and implementation process is clearly defining the system goals, getting agreement on these goals from all internal stakeholders, and ensuring that those goals are well understood by the system developer or vendor. This challenge persists throughout all phases of the project, as goals evolve through different stages. Author Mike Cohn describes software development (or, as is being discussed in this paper, procurement and implementation) as a communication challenge between the technologists who build the software, and the business or customers that will use it. Cohn notes that communication between these groups is fraught with potential for error, stating: “If either side dominates these conversations, the project loses.”² Because these groups approach the work from such different backgrounds and perceptions, it can seem as if they are speaking different languages. 

However, there are tools and methods that can be used to help manage the change process, level set the conversation to a shared understanding and common set of terminology, and ensure strong communication between all involved parties. For technology efforts like digital asset management implementations, usage scenarios (hereafter, scenarios”) are one of those tools. Usage scenarios put the user front and center, a reminder that the technology is being implemented to serve people and help them achieve specific goals. Scenarios are created by the business, and used as a starting point for conversation around stakeholder needs and goals with technologists. Scenarios describe a situation in which one or more users would execute a task or set of tasks using a system. They ground the conversation in a consistent and easily understood format, providing a starting point for ongoing communication and action, helping ensure that no one side will dominate. And, importantly, scenarios keep the why of the project at the front and center, a question which will be continually revisited throughout.

This paper explores a few ways that scenarios can be used throughout the DAMS selection, implementation, and deployment process. It argues that a set of scenarios that are agreed upon by all key stakeholders provide a meaningful testbed of information that can serve as a tool for ensuring consistency, transparency, and measurability, connecting all phases of the technology implementation lifecycle. While this paper is written with the perspective of the DAMS manager/owner in mind, system vendors may also find these recommendations useful to incorporate into the client onboarding process.

Defining Scenarios

Usage scenarios are narrative descriptions of interactions between one or more users and the system. Most importantly, scenarios are stories. Advocates Mary Beth Rosson and John M. Carroll note that scenarios, “consist of a setting, or situation state, one or more actors with personal motivations, knowledge, and capabilities, and various tools and objects that the actors encounter and manipulate. The scenario describes a sequence of actions and events that lead to an outcome.”³

The idea of using scenarios in system design gained strong support in the early 1990s. Finding that using requirements alone defined a limited view of the system, and most importantly, lacked the human component, engineers began to explore the use of scenarios as a technique to compliment the requirements development effort. As human-computer interaction emerged as a critical area of research and development, numerous papers, books, and tutorials were contributed to the growing volume of literature on this topic. Scenario-based design and development is also closely aligned to the human-centered design process, or design thinking, which is an approach to creative problem solving that focuses on understanding human needs first.

Scenarios are attractive and widely used in technology development and deployment projects for a number of reasons, perhaps most importantly because of their simplicity. Requirements engineering author and thought leader Ian Alexander notes that, “Scenarios are a powerful antidote to the complexity of systems and analysis. Telling stories about systems helps ensure that people—stakeholders—share a sufficiently wide view to avoid missing vital aspects of problems.” He adds, “Scenarios are applicable to systems of all types, and may be used at any stage of the development life cycle for different purposes.”⁴

Scenarios describe expected every day use of the system, and can be created from different viewpoints to serve different functions. Two of these views that will be explored in this paper are defined by researcher Alistair Sutcliffe:

• “a story or example of events as a grounded narrative taken from real world experience,” and,
• “a future vision of a designed system with sequences of behaviour and possible contextual description.”⁵

The future-facing scenario perspective will be most useful during selection, implementation, and launch phases of a DAMS initiative, with a shift to current state scenarios during and following launch.

Creating Scenarios

Scenarios are fairly simple and quick to create. They don’t require specialized knowledge or expertise to develop, although following a few best practices will result in more effective scenarios. Their greatest strength is that they are easy to understand and thus it is easy for the stakeholders they represent to provide feedback on them.

When drafting scenarios for DAMS projects, authors should considering including, at minimum: 

• Unique Identifier for each scenario
• Title/simple description
• List of participating actors (archetypal personas based on the organization’s users and roles)
• Narrative description (1-4 paragraphs)
• Expected outcome or success criteria (the things that must be true for the scenario to be accepted by stakeholders once implemented)

Below is a simple example:

Effective scenarios should:

• Follow the 80/20 rule: At minimum, be sure to capture cases that represent 80% of the institution’s anticipated use of the system. However, don’t entirely neglect the edge cases—some of these may prove critical later on. 
• Be constrained to a specific situational goal and outcome: If a scenario is becoming to long and includes multiple end state goals, consider breaking it into multiple scenarios. However, if you need to describe alternatives, these can be added as an additional component to the original scenario. For example if a scenario describes a checksum validation process, include the successful outcome in the main narrative description (e.g., all files pass), and create an alternative path for the case when there is a failure (e.g., one file does not validate).
• Not be prescriptive: In their book, The Right Way to Select Technology, authors Tony Byrne and Jarrod Gingras note that when writing scenarios for the purpose of technology selection, “You want to leave it open-ended enough so that the vendor can do the prescribing of how their solution best meets your needs. So, in your stories, talk about what employees and customers do, but don’t go into too much detail about how they do it.”⁶
• Not include subjective or personal preferences: Statements such as, “the user finds the interface intuitive” are not easily measurable as each user will have a different interpretation of “intuitive.”
• Be demonstrable and testable: A vendor should be able to show you how their tool solves the scenario and/or the users should be able to complete the described tasks themselves during testing (see Implementation, below).
• Strive to remove assumption and internal biases: It may help to enlist an objective third-party to help create scenarios, or provide feedback on existing drafts. Internal stakeholders are more likely make assumptions—such as using terminology that holds an agreed upon meaning within the institution, but may be interpreted differently by others—that an external party would not.

Selection

In his paper “Scenario-based Requirements Engineering,” Sutcliffe states: “Scenarios are arguably the starting point for all modelling and design, and contribute to several parts of the design process.”⁷ System selection and/or development is a typical starting point for scenario creation. At this stage, scenarios serve several primary functions. 

First, scenarios create agreement and buy-in amongst stakeholders about how the future system should work. Before a DAMS RFX is issued, a team should spend considerable effort defining and documenting what they would like the system to enable at their organization, and goals for how they would like the system to work. This documentation will take several forms, including business requirements (why the system is desired), functional requirements (what the system should do, at a granular level), and non-functional requirements or constraints (including technical and hosting requirements, performance requirements, format and other data requirements, etc.). Scenarios accompany these to round out a set of requirements.

At this stage, it is especially important that this process is inclusive of all key stakeholders—in the experience of this author, some DAM failures can be traced to the requirements process not involving the right people, and important needs not being considered during selection. By participating in the scenario development process, stakeholders are given the unique opportunity to think creatively about how they want to be able to work in the future, and what those improvements will look like compared with their current situation. This also helps people feel invested in the system selection process, and will help them see themselves as users of candidate systems that are demonstrated, which will result in more meaningful input during the final decision process.

For an RFX, typically around 6-12 scenarios will be created. Each scenario should describe a typical use of the system. When sketching out ideas for scenarios, it is not uncommon to find multiple ideas that ultimately illustrate the same set of functionality, with a few slightly different parameters (e.g., organizing assets from an event, organizing assets for a project). In these cases, only one scenario that captures this set of goals needs to be created. For the benefit of stakeholders who may become disappointed or frustrated if their needs are not explicitly reflected, the scenario may include a section listing “also applicable to” workflows.

Scenarios created for the purpose of DAMS selection should reflect future state, and paint a picture of what the organization expects the system will enable once it is launched. This author has helped numerous organizations draft scenarios for DAMS, and finds that often stakeholders struggle with two aspects of this process: 1) shifting their thinking to the future, rather than current, state, and 2) committing to scenarios when the workflows haven’t been finalized yet. Stakeholders will often need coaching and multiple rounds of feedback to help them overcome the first hurdle. For the second, it is important to remember that at this stage, scenarios don’t need to align perfectly to future workflows. These will not have been defined yet, and if they have, they will undoubtedly be tweaked following the implementation of new technology.

The second function of scenarios at this stage is that they illustrate for software vendors/developers how the system will be used. Scenarios allow vendors to better understand the institution and the goals of the RFX, and to craft more tailored responses. Scenarios give a sense of the different actors, and their roles and motivations. They bring to life specific individual requirements and tie them to real-world usage. When reviewing an RFP with a list of business, functional, and non-functional requirements, vendors can only gain a certain degree of understanding of how an organization will use the system. By adding a set of scenarios, those requirements come to life.

Scenarios can also become an important part of the vendor’s proposal. By including a scenario worksheet, and asking vendors to describe how their system would fulfill each scenario, an organization can not only learn more detail about how each system works, but can also get a sense of how well the vendor understands their needs and goals through their response. Vendors can be asked to include additional information including preconditions (configuration, customization, or other set up that must be in place before the scenario can be fulfilled) and an estimated timeline for implementation so that this scenario can be tested by users. This information helps reveal which systems are more readily able to support the organization’s needs out of the box, and which will require (potentially costly) customization. These responses can become an important criteria amongst others (budget, requirements alignment) that are used to narrow down a field of candidates to 2-3 that can be invited for demonstration.

The previous scenario example can be transformed into a vendor response table as follows (blue shaded cells to be completed by respondents):

Finally, scenarios provide a testbed of material for system demonstrations, enabling an apples-to-apples comparison of how different systems would fulfill each situation. Once the candidate pool is reduced to a handful of top systems, asking all of these vendors to demonstrate the same subset of scenarios (typically 3-5) and using assets and metadata provided by the organization enables stakeholders to get a real sense of how the system will work. In contrast to a standard demo, which the vendors have rehearsed time and again and are designed to show the best of the system, scenario demonstrations can reveal flaws and aspects of the site that are less streamlined. In other words, they help demonstrate how it really works for the specific users.

Implementation

Scenarios can play a vital role during the implementation process by providing a foundation for further refinement of requirements and definition of completeness for launch phases. One way to approach DAMS implementation is to use an Agile framework. As noted by the Agile Alliance, Agile is simply, “the ability to create and respond to change.”⁸ Agile emerged as an approach to building software so that inevitable changes in focus and priority could be easily managed. Frameworks such as Scrum, which emphasizes cross-functional project teams and consistent development cycles known as “sprints”, have been applied to other contexts outside of software development. Agile is an ideal fit for DAMS implementation, given the number of stakeholders and unknowns, and the need for clear structure and communication. 

Scenarios provide an excellent starting point for the development of user stories, a human-centered communication tool from the Agile community, which describes individual system features from the perspective of a user. Once a DAMS has been selected, the original scenarios should be revisited. During the time between system selection and the engagement with a DAMS vendor or developer, additional needs may arise. Scenarios provided in the original RFX likely need to be updated, refined, or expanded. Additional scenarios may need to be added. 

Following the revision process, a set of agreed upon implementation scenarios will be available. These can also be deconstructed into discrete individual user stories, which take the format:

As a _[actor]_ I want _[goal/desire]_ so that _[benefit]_. 

User stories can be written for each functional aspect of the system that is described in a given scenario, ensuring that all success criteria are met. User stories can be accompanied by acceptance criteria, which are conditions that must be satisfied in order for the product to work as intended by stakeholders.

For example, given the previous scenario example, a number of user stories and acceptance criteria can be derived. Two examples might be:

These can be categorized according to type (e.g., search, metadata, integration), and can be prioritized according to their importance for the relevant stakeholders. The user stories can then be delivered to the system vendor, along with the scenarios, for initial setup and configuration of the system, and/or to internal stakeholders responsible for additional configuration. 

Once a set of initial user stories are created, two testbeds of material will now be available:

1. User stories, which can be tested and validated individually, according to provided acceptance criteria
2. Usage scenarios, which can be tested and validated by the identified actors to ensure that the entire workflow can be completed, according to the provided success criteria

The user stories derived from implementation scenarios will not reflect all the requirements that users have for the system, but it will provide an initial set of stories that are rooted in the original scenario, which will become useful as the launch phase approaches. As implementation proceeds, and new needs arise, new requirements can continue to be created in user story form. 

Getting to Launch

A scenario-driven approach to DAMS selection and implementation enables what can be termed test driven deployment. This concept is borrowed from test driven development, an approach to iterative software development that relies on writing tests first, then writing code to reach a minimum level of functionality required to pass those tests. In test driven deployment, scenarios and user stories are tests in and of themselves, and thus become an ongoing component of implementation and launch phases of DAMS deployment. Throughout implementation (and beyond), the scenarios and user stories will become important tools for testing, providing feedback, and measuring progress toward launch goals. Again, this process will naturally fit into an Agile framework. 

It is important to establish a clear scope for an initial launch candidate. This scope should include definition of the user stories that must be completed and validated. Bear in mind that users needs will continue to evolve and grow, so keeping a backlog of stories to be prioritized and addressed over time is critical. However, communicating the goal of incremental deployment, and maintaining a transparent user story backlog will help manage user expectations and avoid scope creep.

Acceptance of the initial launch candidate will require completion and validation of all user stories prioritized for this milestone. Prior to engagement of end user groups, all user stories should be tested and validated by the DAMS owner/manager, then by key stakeholders. This exercise will likely result in discovery of bugs, incomplete stories, as well as some additional user stories that need to be implemented prior to full acceptance, and should be communicated back to the vendor. Maintaining use of the user story format will ensure consistency in communication throughout this back and forth process.

As launch approaches, teams will begin testing and training within the system. One useful test is to ask these groups to walk through the relevant narrative scenarios and success criteria, working through the outlined steps within the system, and determine if they are sufficient for launch. While additional user acceptance testing may be performed as well, scenario tests are important for tying deployment back to original requirements that stakeholders are already familiar with.

This entire cycle can continue as additional teams are brought on to the system. New teams who weren’t engaged in the initial selection and implementation stages should go through the same process, starting with the development of scenarios, followed by the create of prioritized user stories. Scenarios can also be used to craft meaningful and easy-to-digest training materials, and used as part of training sessions. Providing new users with example situations help make the system more relatable.

Ongoing Improvement

Scenarios can also play an important role over time to create system improvements. For system enhancements, scenarios can be used to communicate the future state goal, and the changes that might be required to reach that state. For bugs or other issues, scenarios can be used to describe the user’s experience when they perform a given task, or what happens when things are not working as expected. In this case, the framing of the scenario should shift from future state (as has been suggested throughout this paper) to current state, which is the other type of scenario defined by Sutcliffe: “A story or example of events as a grounded narrative taken from real world experience.”⁹ The scenarios created at this stage could be termed what Sutcliffe refers to as “problem statement scenarios.”

Furthermore, ongoing user testing should also be an important part of a DAM program, so that the product owners can understand how users are working in the system, and what improvements could make their experience better. Scenarios provide an excellent starting point for the creation of task-oriented user tests, which can be delivered to participants in moderated or unmoderated sessions.

Conclusion

Scenarios are not a panacea and certainly not the only tool in your toolbox. However, consistent use of this format can facilitate clear communication between all parties involved in the DAMS selection, implementation, and management process. All technology projects run the risk of failure at worst, and transforming how the organization works at best. Communication is one of several critical factors that will contribute to the outcome.

Scenarios help communicate the project vision. They can support stakeholder engagement and buy-in. They enable traceability of system features to original requirements. They support testing. The simplicity and clarity of scenarios and user stories make them excellent documentation and training resources.

One important advantage of scenarios is that they are extremely lightweight. DAMS initiatives inevitably result in a great deal of documentation, and readers may feel a reluctance to add more. However, the experience of this author is that a set of key scenarios—just a few short paragraphs each—has the potential to make the selection, implementation, and launch processes streamlined and understandable to all stakeholders. As Byrne and Gingras emphasize in The Right Way to Select Technology, “After defining the business case, [scenario creation] is the most important foundational work you will do, so spend time to get it right.”¹⁰

References

1. Marr, Bernard, ‘Are these the 7 reasons why tech projects fail? Forbes; September 13, 2016.

2. Cohn, Mike. User Stories Applied. Addison-Wesley Professional; 2004. Page 3.

3. Carroll, John M., Rosson, Mary Beth. Scenario-Based Design. In Jacko, J., Sears A., editors. The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Lawrence Erlbaum Associates; 2002.

4. Alexander, Ian, Maiden, Neil. Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle. 1st Edition. Wiley; 2004. Page 3

5. Sutcliffe, A. (2004) ‘Scenario-based requirements engineering’, in Proceedings of the 11th IEEE International Requirements Engineering Conference, Monterey Bay, CA, 12th September, pp. 320–329.

6. Byrne, Tony and Gingras, Jarrod. The Right Way to Select Technology. New York: Rosenfeld Media; 2017. Page 43.

7 Sutcliffe, ref 5 above

8. Agile Alliance. (n.d.) ‘Agile 101’,(accessed 9th April, 2019).

9. Sutcliffe, ref 5 above

10. Byrne and Gingras, ref 5 above.