How to formulate effective User Requirements?

Coming back to Jochen König's post about the relationship between system quality and requirements management (Why system quality starts with business requirements quality) I would like to add some hands-on examples.

When entering a shoe shop to buy some new ones for a specific purpose, it is advisable to think about desired features, appearance, sustainability or situation to wear beforehand.

However, usually the situation is different. You are entering a shoe shop with your kids, partner or friend giving you advice:

• Take the pink ones with glitter, Mommy, they look great!

• I would take the black ones as they do not look dirty that fast.

• Let's buy pumps instead of running shoes to go out tonight!

And the nightmare takes it course leaving the shoe shop with pink glittery pumps you will not be able to wear in muddy forest for your next training session. To go out at night failed as you are totally tired and just decided to choose the couch for spending the evening.

Sounds quite familiar to my digitization project situations where we usually have not only one business representative to collect and especially formulate requirements but several ones from different departments. In the middle of this, solution architects totally confused, trying to design suggested requirements into the new tool. What a mess, usually ending in a lot of very general or ill-fitting requirements formulated to finally escape from these exhausting workshops.

Ineffective requirement

"I want a button to schedule production so that we can make new material."

We at bpExperts believe this is where applying a clearly defined Business Process Management (BPM) methodology provides guidance throughout the requirement collection sessions and helps visualizing the corresponding discussion points.

A sequence flow in our business scenarios visualizes inter-department or inter-domain interactions where input data from one domain is required to fulfill the subsequent business scenario in another domain. Predecessors and successors are visualized to summarize the flow from end to end.

Pl2P Make-to-order business scenario from Business Flows reference content.

For each specific process an adapted SIPOC (successor - input - process - output - consumer) technique guides finding all elements for formulating effective requirements related to departments & business roles, input and output data, relevant compliance topics, etc., that need to be considered or KPIs that are supposed to be achieved.

SIPOC including compliance relevant topics.

Effective requirement

"As a Production Scheduler, I want to be able to quickly create and schedule planned orders for new product launches in the production planning tool so that we can efficiently meet the market demand within the Make2order scenario and optimize resource utilization. "

Looking at the figures above, you will find it easy to see how the 'effective requirement' references the model and thus provides the context and detail for a 'right first time' solution design and implementation. Where needed, the models also guide business or solution architects in fleshing out further details, e.g. on required data or regulatory boundaries. And maybe most importantly, the model context enables prioritization and sequencing requirements from a business (value) perspective.

In summary, the activities around requirement collection may look costly and time-consuming. However, it enables your team to elaborate about a specific requirement in detail, learning more about the surrounding environment and the end-to-end-flow throughout the company. Especially business representatives in digitization projects get a clear structure to nail down their requirements specifically and reducing the extra effort later during implementation, testing or training when requirements have not met their expectations.

Please get in touch if you want to learn more about process management capabilities to facilitate your requirement engineering.

Why system quality starts with business requirements quality?

Imagine walking into a large sports equipment store, telling the clerk you'd need some sports shoes. You can expect that this level of 'requirement' will not even get you to the right part of the store. Even asking more specifically for running shoes will only take you to a vast set of shelves with models ranging from sprinting spikes to cross-country trail running shoes. It is obvious that formulating specific requirements here is fundamental for being served well. Obviously, an experienced clerk will support you in formulating and refining your requirements by asking the right questions, and having you try on certain models. In the end you will be able to take an educated decision if the offer meets your needs and taste, and budget.

This is the happy path of requirements engineering. But imagine you are yourself uncertain of what you need or exaggerate on your current skill or ambition. In this case you may well end up with shoes of perfect quality but not matching your actual need at all. Likely a waste of money and not fun to run in.

You wonder why formulating and capturing high quality requirements is neglected so often in business transformation projects, especially those involving IT system implementations.

Waterfall and agile frameworks have the tool set to break down high-level user demands into more and more detailed pieces amenable for development and testing. In either case, accurately capturing the user or business need is the pivotal starting point. However, working top down from a set of starting requirements bears the risk of missing out on critical (starting) requirements or insufficient context.

Especially for complex systems, we at bpExperts GmbH believe that a process-centric approach to requirements engineering – founded on high quality process documentation – is the most robust and sustainable to address the concern above. IT systems are meant to support business processes following strategic and operative objectives. Process-centricity promotes and enforces this ensuring that the needs and expectations of all stakeholders are met, leading to higher satisfaction.

Effective Implementation

The clear association of requirements with the supported business process and objectives enables prioritization and focus on the most value-adding features and capabilities. With this it will be easier to formulate a robust, value-oriented and therefore future-proof implementation strategy, and define a development roadmap starting from a first release or minimal viable product to more mature and functionally enhanced subsequent releases.

Efficient Development

Contextualising requirements with the supported business process and anticipated business outcomes enables developer to see the bigger picture and ask the right questions in case information is missing. The more agile the development process, the more important it is to facilitate collaboration and decision making. Process-orientation provides a reliable reference for understanding dependencies and limitations and connects higher and lower level requirements comprehensibly. In a waterfall setting, this approach enables assessing the completeness or requirements (in scope and content) before the actual development start and thus avoids inefficient change requests.

Quality Assurance and Testing

Especially for complex systems, comprehensive testing of all conceivable paths and functionality combinations is hardly possible nor meaningful. Instead, the established practice is to adopt a risk-based approach to testing. For estimating the 'Severity' of a potential impact it is vitally important to connect a requirement to its contribution to the anticipated outcome. Connecting a requirement to the process supports estimating how often a requirement and the resulting capability or feature will be leveraged and thus drive establishing the 'Occurrence' likelihood. This way, well-written and –anchored requirements enable rational and effective test strategies, easily justified during audits.

In summary, just like the fish rots from the head down, low quality requirements are bound to lead to bad quality or ill-fitting systems. They should be worked out and documented as the starting point for any implementation activity. That does not rule out that requirements may need to be refined, sliced and diced on the way but make sure to not trick yourself. "Reverse engineering" requirements for an existing solution is likely not giving the benefits outlined above.

Anchoring requirements to the business process and business objectives, makes writing high quality requirements easier by supporting comprehensiveness and comprehensibility. High-quality business requirements lead to systems that are not only operationally efficient but also strategically aligned with organizational objectives, providing sustainable value.

Please get in touch if you would like to learn more on how to establish and leverage Business Process Management to support your transformation initiative.

Why the transformation project manager should be a business transformation catalyst.

Imagine you want to buy a new kitchen for your flat or house. Who would you trust more to help you get the layout and appliances that will keep you satisfied and happy for years - a designer from a particular manufacturer or an independent, passionate cook?

Despite the fact that every 'digital transformation project' really is a 'business transformation project' the project manager of this transformation will regularly be selected for their IT merits. Of course, there is nothing wrong about a solid technical background. However, I argue that the ability to understand, consolidate and track business needs and requirements, and thus act as a business ally is more important.

In earlier posts my colleague Dr. Russell Gomersall and I already stressed the point of involving business stakeholders and users early in any transformation and making sure to take the business users along through effective change management. Consequently, the Transformation Project Manager should be the guardian of business value and thus is instrumental for keeping the project goal and project execution aligned.

The need to have the Transformation Project Manager as a business ally increases with the size and complexity of the transformation, i.e. the number and diversity of business processes to be considered. The Transformation Project Manager will need to assure the project's focus on what the business needs rather than what has explicitly been requested or what the vendor "always" delivers, 'best practice' or not. The Transformation Project Manager must go beyond project administration and keeping the ball rolling. Below are some aspects worth considering.

Alignment with Business Objectives and Transformation Risks

Since project resources (esp. people, time, and money) are always limited, only understanding the business objective and its relationship to the deliverables will enable actively managing the transformation to provide the best output and value-adding outcome. The Transformation Project Manager does not have to be an expert on the specific business process but be acting as a catalyst for decisions on project priorities within business and technical boundary conditions. He or she would make sure the business need is captured comprehensively and comprehensibly for all parties.

This transparency, supported by clear priorities, is the essential prerequisite of both sequential (waterfall) and agile implementation strategies.  And, you may have guessed that from my background, I am convinced that Business Process Management (BPM) is the discipline that most efficiently facilitates capturing and maintaining the required information and makes sure business and technical teams have a common coordinate system.

Regardless which implementation approach is selected, any larger transformation will have to address (adopt, adapt or fend off) requests for changes along the way. The argument for any response should start with the business value, and then balance it against the related effort (i.e. cost) and timeline impacts. Likewise, project risks should be assessed and acted upon relative to the capability to meet the transformation's business objectives.

Stakeholder and Change Management

Clear, business value-aligned priorities of the transformation are instrumental to answer the two principal questions change management must be able to address: 'What is in it for us?' and 'What is in it for me?'

Understanding the value proposition of the project top-down and bottom-up helps the Transformation Project Manager shaping change management strategies that are convincing rather than persuading. This will be even more important as most project stakeholders, especially when they are active project members will have the transformation assigned to them on top of their regular operational tasks.

Measuring and monitoring the progress and success of transformations all too often is based on what is easy to measure, rather than what is representing the anticipated benefit. Choosing the right metrics is an art that should be performed from a business perspective.

Conclusion

The points above would seem like asking for a kind of project manager super-hero or unicorn that my colleague Dr. Ikemefuna Allen wrote about, understanding all business and IT aspects of the initiative. Instead, I prefer the catalyst analogy, where the Transformation Project Manager supports or creates an environment where business and IT experts can interact and co-create desired outcomes. A solid basis in Business Process Management should always be considered an asset in the Transformation Manager's toolset.

A Transformation Project Manager as a business ally ensures that the project is not just technically successful but also brings value to the business, aligns with its strategic objectives, and is adaptable to its needs. This approach significantly improves the chances of the transformation project being both successful and beneficial to the organization.

Spring cleaning rituals in SAP Signavio (using API & Scripts)

"For the sake of the efforts invested in building BPM content and the BPM community, the objective of introducing process-centric thinking is not merely to 'survive' one project; it's about establishing BPM principles for the long term.

In this context, many analogies can be drawn to living in a house.

The 'fast and furious' approach to setting up a repository is all about moving in. You may recall being invited to help somebody move, and you arrive on time, only to find that nothing has been packed efficiently (or at all). Everything is then dumped loosely into the lorry, requiring you to make two trips. Upon reaching the new house, the boxes haven't been labelled properly for the helpers to know where to place them.

Now, let's assume everything went well, and you have settled down. Over time, changes occur: new processes are introduced, processes are optimised and updated, and new use cases require you to adapt the methodology, add attributes, and maintain process owners, etc.

In real life, this is the situation of living in a house over time. If you are single, you may be able to control what happens. However, the BPM house is more like living in a house with four kids, a dog, a husband with many hobbies, and a tendency to collect and keep things 'just in case.' Everyone is constantly bringing things home and dumping them somewhere. Of course, you have house rules; however, not everyone may pay the necessary attention. So, every now and then, you (your family) need to tidy up.

Does this sound familiar? Yes, and everyone working in a BPM organisation will understand what I am talking about when it comes to housekeeping your BPM house.

The question is, what capabilities are required to support your housekeeping? Beyond the obvious semantic check and quality assurance of maintained attributes according to your conventions, there are additional questions that need answering:

• Are there redundant diagrams or dictionary items (duplicates)?

• Are all diagrams placed in the correct folder, and dictionary items placed in the right category?

• Are all diagram assignments consistent and correct?

• Is the naming of objects in diagrams and linked dictionary items consistent?

• Which 'orphaned' diagrams and dictionary items are there?

Getting these questions answered can be very time-consuming. Analogously to our script-based approach for migrating content, we have developed a report that answers these questions and will be as helpful as a Dyson vacuum cleaner when it comes to housekeeping in SAP Signavio. Basically, it extracts all the metadata from the repository and presents it to you in a manner that helps identify all the elements you need to check and consolidate.

The following figure shows you an extract with some example findings:

Fig. 1: Mismatch of task and assigned diagram

A good practice is to be consistent about naming a task and the assigned diagram. It can be tedious finding mismatches or just typos. Here the report directly shows discrepancies.

Fig. 2: Orphaned diagrams in temp folders

Many times diagrams are drafted and placed into temp folders. When looking into the search, you may therefore find multiple entries. Tidying up regularly helps.

Fig. 3: Process without assigned diagrams

Also, depending on your conventions, you want to check if all process hierarchies can be drilled down according to your hierarchy. Checking all models can take some time. Here again, the report helps identify processes you need to check.

To summarize, housekeeping your process repository is essential to keep the usability and overall value high. The more mature your process repository becomes, the harder it is to maintain a high quality. The in-built reports don't support you sufficiently as they neglect your individual use case, process architecture and conventions. With the help of little 'helper-scripts' the work can be made much easier

We are convinced this little tool is of great household use, and everyone should have one. So, if you are interested, maybe you could reach out to us, and we can schedule a free demo, or discuss your specific requirements."

Why is Change Management dropped so often during implementations, and how can this be prevented?

Procrastinating involving the business in planning and shaping your large system implementation as outlined by Dr. Russell Gomersall in his post "Are you also procrastinating about getting your business involved in the preparation of your HANA initiative?" is bad enough. But neglecting taking your future user base along and enabling them to actively embrace the change is asking for failure of your initiative.

Neglecting the need for investing into Change Management often is the result of classical group-think. The members of the Steering Committee and the project leaders spent significant efforts discussing if the project is needed and what its scope should be. They came to the conclusion that the change is needed, have weighted the risks and see the future benefit. - With a case so clear, how could anyone still have doubts or be reluctant?

Another reason for neglecting the need for change management is the focus short-to-mid-term urgency. Internal and external resources need to be staffed, technical decisions need to be made, project plans crafted, and issues resolved to start creating any change. And funding is short anyway. - Let's wait with the users till we have a clearer picture and know what still fits into the budget.

Obviously, this is short-sighted.

The more central a system is to an organization's operations and the larger the number of direct and indirect users of that system, the more important it is to actively manage the change. Leaders need to understand that the organization will have gotten used to the old ways of doing things and employees will have optimized their ways of delivering the best possible job with the old system. There will always be uneasiness or fear of what the new system will bring, and if the colourful promises will materialize even remotely.

Moving from one stabile state to another takes overcoming the required activation level. You will not succeed having a tea party by just anticipating how nice it would be or assuming that everyone would agree to come or by writing the best recipes.

Change management not only channels the required activation energy into the organization, it also makes sure you do not end up with a bonfire. And that is also why change management is not 'just communication'. At least when communication is understood as repeatedly preaching a message without listening to, and understanding the audience first hand. Therefore, communication really must be conversation, a truly bidirectional exchange.

The key to not fall into the trap of change management dropping out of the project scope is to create and maintain awareness of the magnitude of change within leadership. The bigger the change the more important it is that leadership provides their support, and expresses it authentically and believably, and on many levels.

Engaging dedicated support for the taks will be instrumental. Shaping and executing change management is not a side dish of the project manager. You may find interested and capable talent inside your organization or hire external professionals. In any case the change manager should understand your business (processes) and the goal for changing.  The change manager's prime task is to catalyse creating and executing the change strategy with clear and consistent messages, regular monitoring follow-up, and the willingness and capability to bring feedback to the project team.

In bpExperts we have gathered many years of experience of preparing, scoping, and supporting the implementation of process-driven change of IT systems and organizations. We have developed the capabilities and approaches to help you taking the natural inertia above and beyond the activation level and guide it to the desired state:

We care, we act, we deliver!

Squeezing change management out of the budget will dramatically increase the risk of the project. Do you recall the old wisdom 'Culture eats strategy for breakfast'? - It is the same for new (strategic) systems and operations. If you do not win your users over, the implementation will fail; probably even before any deployments.