If you are considering Digital Performance Support (“DPS”) as part of the on-boarding and user experience for your application or application project, it’s important to know, as with any new capability, there’s a right way to do it and there’s definitely a wrong way.
At Epilogue, we’ve been involved in hundreds of DPS efforts with our customers and partners as they’ve incorporated DPS into their projects, applications and enterprises. As a result, I’d like to share our view of the most important fundamental elements needed to build a foundation for successful Digital Performance Support which, in turn, will help lead to successful on-boarding and sustained use of your application(s).
If you need a general refresher on DPS, in an earlier blog post I described two general approaches to DPS and in this blog post by a frequent blogger on the topic, Gary Wise, where he does a nice job of describing DPS, which he calls Embedded Performance Support.
Back to building the foundation. It starts with making sure your tools and methods are suitable for building the supporting foundation from which effective DPS will rise. Foundations are comprised of layers, each laid in the right sequence and in the right way. For Digital Performance Support, there are three primary layers to a strong DPS foundation:
At the 10,000 feet level, Digital Performance Support is about getting the right embedded application support to the user at their moment of need so they can perform their job and contribute to the desired business outcome for which your application is intended.
To do this, you’ve got to have the right kind of content that helps the user know how to perform a process, transaction or workflow = CREATE.
That content needs to get in the hands of the user when they need it most, as they are performing the process, transaction or workflow = DELIVER.
Then, there’s got to be a way to stay on top of the content and the people involved in creating and maintaining it = MANAGE.
CREATE is where DPS efforts die 90% of the time. Why? Because very few organizations, project teams, L&D and Education Services groups have the staff, budget and time to adequately document applications. Without the right tool, it’s way too hard and takes too long. As a result, user documentation is usually thin in breadth, depth and accuracy in representing the actual screens and workflows in front of the user. Further, generating content in the variety of formats that work for users is rarely done for the same reasons.
The bottom line, if you can’t document your application and generate user content in the depth, breadth, accuracy and formats needed, the other foundation elements, DELIVER and MANAGE, won’t matter. Why? Because users are unforgiving of anything that is not clearly helpful and DPS will fail due to lack of adoption and sustained utilization. Also, things change over time, particularly with cloud applications. Content that cannot be easily maintained for accuracy will cause users to lose faith in DPS.
Therefore, the starting point for a successful DPS initiative requires the ability to document applications quickly, easily and broadly.
· What I mean by document is capturing how the application works from a user’s point of view — the processes, workflows and transactions required of users. Then, generating the types of content formats that meet the varying needs of users — job aids, process and procedures, simulations (watch & listen, interactive and testing), process flows, step-through navigation (takes the user step by step through a process or transaction allowing data entry as they go) and so on. BTW — having the ability to leverage these artifacts into eLearning and other training needs further extends the value of this documentation effort.
· What I mean by quickly is minutes, not hours or days as occurs with the wrong tools.
· What I mean by easily is that creating should be so easy that any SME can be involved in the actual creation, not just a small number of highly trained staff — the best use of that highly trained staff is in the oversight and management of DPS.
· What I mean by broadly is that more than just the top 10–20% of an application should be documented — 40–80% of most applications are important enough and complicated enough to warrant documenting. Don’t cause your users to unregister DPS in their minds as useful when they can’t find what they need because it doesn’t exist.
DELIVER is where DPS generates true value. If you are able to do #1 CREATE in the necessary breadth, depth, accuracy and formats needed, then the only way to generate value is to get the content to the user at their moment of need and with the most minimal of effort.
Therefore, achieving value from DPS requires the ability to deliver Performance Support at the moment of need … effortlessly.
· What I mean by Performance Support is the content generated in CREATE, which we call Performance Support.
· What I mean by at the moment of need is just that — as the user is working in an application, Performance Support is available to guide them through processes, workflows or transactions efficiently and effectively with sufficient process related information and context to decrease errors, omissions and rework.
· What I mean by effortlessly is that the user has on-demand access, in 2 clicks or less, to the Performance Support they need. No searching knowledgebases, support portals or a repository index. The Performance Support delivered is narrowed to their job role, the application, process, workflow and transaction on which they are working and, as a plus, also filtered by other organizational metadata or folksonomy.
MANAGE is another area where DPS efforts eventually die, collapsing under their own weight. If you successfully accomplish #1 CREATE and #2 DELIVER, you’ll be well on your way to DPS success. However, over time things change. Over time, applications change configuration as they are modified to accommodate business needs, they are optimized to improve effectiveness, or they are updated by the software maker. Over time, business processes change, regulatory and compliance needs change and new applications are added to your technology stack. A DPS solution that enables #1 CREATE and #2 DELIVER will result in growing Performance Support content volume and growing user adoption as DPS is expanded in use and coverage of key applications. This means more teams will be using DPS to CREATE Performance Support for their functions and their applications. Staying on top of teams, DPS tasks and sustaining Performance Content over time becomes a real challenge.
Therefore, achieving and sustaining DPS success requires the ability to monitor activity and content in high volume, across projects and over time.
· What I mean by monitor activity is the ability to monitor DPS activities such as DPS teams, projects and tasks as well as user utilization.
· What I mean by monitor content is the ability to monitor the process of content creation and, as importantly, sustaining of that content by flagging aging content, enabling user feedback which helps content improvement and identify content issues, and track specific content usage to help identify utilization increases, decreases or lack of use — all good inputs to sustaining content management.
· What I mean by high volume is that success in CREATE and DELIVER will result in a growing volume of Performance Support content and the volume of users and those involved in DPS creation and management. A successful DPS needs to be able to scale and curate accordingly.
· What I mean by across projects is that success in CREATE and DELIVER will result in a more pervasive use across your application and other applications in your environment. A successful DPS needs to be able to scale across teams, projects and applications.
· What I mean by over time is simply that. A successful DPS is sustainable. Sustaining content, sustaining the curation of the process, and sustaining DPS expansion.
The right DPS can be a strong component for your application or your enterprise. My next blog will continue this theme of CREATE, DELIVER, MANAGE by taking a look at methodologies for using DPS taking into consideration application and environmental variables.