PLM business requirements are typically process and outcome driven; they describe an operational intent in the form of expected capabilities and functionalities—complemented by non-functional requirements overlaid to storyboards, based on data volume and access frequencies. On the one hand, building requirements from current AS IS processes might lead to miss-opportunities or miss-alignment with PLM tools, whereas on the other hand “blue sky thinking” or building requirements from scratch might require iterative re-alignments to derive future TO BE processes that are supported by the selected platform. This is clearly a matter of trade-offs between legacy and new processes, legacy and new platforms, change mitigations and data migration, solution adaptation and training needs, deployment feasibility and business adaptability to change.
In this post, we explore how to effectively capture PLM requirements in the form of storyboards and use cases, which in turn will become the foundation of the solution design and deployment.
Enabling effective PLM delivery
Every PLM practice will have its own definition of a business process (a.k.a. workflow), a user method, a use case, a storyboard, a test case, etc. These artefacts are essential elements used to assess business needs, input to design, configuration and validation of the solution; they also contribute to building training material and communicating about the change. Broadly speaking, such artefacts can be defined as follows:
- Storyboards are high-level block diagrams illustrating the bird’s-eye view of a given capability set to achieve specific business outcomes; they can be more or less detailed, focusing on pain points or sub-optimum areas, completed with placeholders to describe what needs to be changed, configured or customized. They can be used as communication tools to flag expected improvements, gaps and areas where more analysis is needed across a wider subject matter or scope. Eventually, larger epic stories can be broken down as required in a number of smaller storyboards.
- Use cases describe repeatable series of actions or interactions between systems and users, flow of events to achieve a certain activity or task; some steps might be manual while others can be automated through integration or system batch job. Use cases are typically converted to test cases when times come to validate the solution, including negative testing (also covering things that can go wrong or are not allowed).
- User methods (or workflows) illustrate operational steps taken by a user to complete an activity; retrospectively, multiple methods and use cases can be combined in the context of a given storyboard. Methods and storyboards are directly used in training materials, even when they represent out-of-the-box processes which will be integral to the user education curriculum.
Business communication at all levels is critical to deliver effective PLM delivery: from Key Users to Executive Sponsors, internal support functions and suppliers. Business value can be validated through experimentation and testing following agreed storyboards and use cases—supporting business engagement and detailed method confirmation during User Acceptance Testing (UAT cycles).
Communicating upstream with the business
Storyboards and use cases are great visual aids to communicate requirements and progress through design solutions committed to the business, including status reviews with Change Leads and Key Users.
Ultimately, storyboards can combine swimlane activity flows representing “day-in-a-life” of a specific function, during their interactions with others and using a number of tools and processes. They need to be created from project outset and refined through ongoing conversations between end-users and implementation teams. Arguably, solution elements might not cover all aspects of storyboards; and equally, storyboards might not cover all requirements of specific solution elements. Storyboards can clearly be used for expectation setting with the business, build expectations for both current and later stages of the PLM roadmap and change journey.
Armed with such artefacts, business stakeholders can appreciate the convergence towards alignment on the solution design and expected functional outcomes—without having to read large blueprint documents or ready-made generic training materials which can be difficult to consume without contextualization.
Communicating downstream with IT and technical implementation teams
In parallel, technical teams and Solution Architects can create solution design specifications based on this input and continue to improve and update as the PLM project progresses through its delivery phases or sprints.
Functional and non-functional requirements from the business are captured through discovery and design workshops as a framework for mutual alignment on the solution to be adopted or developed.
- Typically, storyboards do not cover system integration testing, but they provide business context (alignment with outcome and strategy).
- Use cases / test cases must be exhaustive and cover all bases relating to a goal.
- Use cases that are not met during a given project iteration, sprint or phase can be carried over to the next via a backlog (as a way to plan future work, and pending that the business approves).
Clearly, developing and maintaining credible and accurate storyboards and use cases contribute to building trust with the business; such documentation does not have to be complex and can be broken down on management blocks. Starting with generic storyboards and use cases can be useful; they however need to be quickly and continuously adapted to the business language and requirements to become and remain relevant.
In the next part of this two-part post series, we will debate how important these artefacts are to foster business change adoption, confirm benefit realization, and training needs; we will also cover how they can also contribute to agile delivery.
What are your thoughts?
This post was originally published on Momentum-PLM on 8 September 2020.
Disclaimer: articles and thoughts published on v+d do not necessarily represent the views of the company, but solely the views or interpretations of the author(s); reviews, insights and mentions of publications, products, or services do neither constitute endorsement, nor recommendations for purchase or adoption.
About the Author
