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.

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.

Why project methodology beats implementation methodology?

Do you know this story of the drunk who had lost his key on his nightly way, and then focuses his search to the lit spot around a street lamp post because that's where he sees best? Browsing community and expert forums on how to increase the success rate of IT system implementations, I regularly have the feeling we all must be on our way home from a blasting party. The key to successful implementations - most seem to agree - lies in choosing the right method for turning clearly defined requirements into software. There are those swearing by waterfall, others by agile approaches, and others again swear at either. IT centricity through and through.

In contrast, I argue that the key to any successful implementation is understanding what the (business) customer really wants and needs, and enabling efficient, regular alignments for fine-tuning and integration across communities. And that is where I see a process-centric approach as project methodology as THE winning factor.

Especially for larger systems, numerous technical and business experts need to collaborate on highly specific questions with abstraction levels ranging from business strategy and operating models to execution and monitoring alternatives within individual (sub-) processes. Business process management (BPM) provides a framework to capture and connect requirements across theses orders of abstraction - if you do it right. (Please do not limit BPM to automation and overseeing automated processes here!)

The integrated process models will provide the coordinate system to structure the requirements definition and their continual refinement as more processes and their stakeholders get considered, and as the functional and technical design progress.

End-to-end sequences of integrated models are 'Ariadne's thread' making sure that requirements are comprehensive, test cases meaningful and relevant, and change management is user-oriented. Understanding the requirements in context of their processes enables fact-based and risk-based decisions for adopting a standard solution or investing in customizations. Without the process context, the project is bound to become a maze and neither waterfall nor agile practice will secure a successful implementation. With clearly structured and documented requirements in place however, you can set up your implementation methodology to match the team's experience, working style, location distribution and other criteria that will guide your choice.

Now, certain implementation partners and integration managers may claim that their experience will carry the project, and that building an integrated process model itself would be a wasted effort creating a maze all by itself. However, from my experience, I'd be surprised if they could conclusively demonstrate to you how they will keep up reliable transparency to all stakeholders on aspects like business fit, requirements and test coverage, and avoid the disconnect when talking to users during alignments and training.

Obviously, the process-centric approach goes well with involving your business customers early as Dr. Russell Gomersall discussed previously and keeping them involved as I wrote about in Why is Change Management dropped so often during implementations, and how can this be prevented?

With Business Flows we at bpExperts GmbH have built a reference architecture, process model content, and project templates which enable the business to stay in control of the business transformation. With that in place and the project methodology clarified, you can leave the choice of the implementation methodology to the implementation team.

We care, we act, we deliver!

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.