Methodology Components
system, orderliness, way of doing. Methodology – set of methods used in working
Methodology
or Method Set
Method
A method that covers the total spectrum of projects that should be orchestrated together in order to encompass a total Business Engineering initiative. The following diagram illustrates the base methods set components that could be utilised or covered in a full Business Engineering initiative.
​
The components indicated in the diagram are not positioned in any order or sequence.
Business Engineering
Strategic Positioning
What should your ideal business look like relative to its surrounding environment?
Strategic Positioning
Any project of this nature has to start with the strategic positioning of the business relative to its external- and target environments. As these two environments dictate to a certain extent what the internal environment will look like to be operational within them, it implies that this is the natural point of departure. The definition of strategic positioning is to define components of all twenty-four architectural components (eight facets times three architectural layers) within the context of sixteen influencing factors, five target environmental categories and eleven external environmental categories.
Architecture
Architecture is the change mechanism of organisations. Control over architecture implies control over change; it represents an insurance policy over the changes that an organisation will undergo.
Master Business Planning
Roadmap between the point of
departure (current business) and the destination (future business).
Master Business Plan
For any organisation to catapult itself from one position to the next a migration plan is required. The master business plan is this migration plan of the organisation, which consists of multiple sub plans, which will effect all the required changes to all the processes, resources and structures in order to represent a new business, in a controlled and co-ordinated manner.
​
The master business plan is the road map between the point of departure (the current business) and the destination (the future business). It not only represents the change route or strategy, but also the vehicle that will be used in travelling (the method).
Cost Benefit Analysis
A Business Engineering project implies that assessments have to be compiled pre-, midand post project to determine the continuous financial viability of the venture. The initial components of the venture have to finance the following, i.e. the project should fund itself.
Business Process Re-engineering
A Business Engineering initiative typically results in the combination of a number of projects that are executed simultaneously as well as chronologically. These projects could vary from business process re-engineering, to information system or other resource alignment and training or restructuring projects.
The problem with a number of change initiatives that are executed simultaneously is that they have the potential for lacking synergy in terms of their contribution to an integrated business solution. A number of change initiatives, thrown together, are difficult to coordinate as there are inevitably result dependencies between them. The architectures of the independent solutions have a significant impact and preferred development sequence between them. The only way of executing a complex initiative, consisting of multiple simultaneous projects, is to provide architecture as an initiating catalyst. This will enable all the projects to be executed within an architectural framework, which provides the projects with the correct scope, content and context relative to one another. Architecture represents the insurance policy over change.
Legacy Modelling
Searchable database containing information about the business
Business Encyclopedia
Unfortunately very few organisations have business encyclopedias, which contain up-to-date information about the business, available. Without information like this it is virtually
impossible to capitalise on existing knowledge about he business. If one was to ask twenty people in a large banking business to define the ‘credit’ process or area of the business, one is bound to get twenty different answers. Without this kind of information it is impossible to fix an area of their business for them. One would not be able to determine exactly what is included, what is excluded, who should be involved and who must be exposed to the initiative. This unfortunately implies that we have to spend resources to understand what the current definition of the business is. Without one consolidated, commonly agreed-on understanding of the point of departure one would not be able to migrate to a new.
Package and/or Technology Evaluation, Selection and Implementation
Package Evaluation
This involves the compilation of a list of potential packages that exhibits functionality similar to the required functionality. This is usually obtained by researching the competitor environment and in some cases by Request For Proposal (RFP). The RFP typically contains a superficial description of the company profile and required functionality. Hopefully, some sort of business analysis has been performed prior to specifying the package requirements.
​
The actual evaluation concerns the suitability of the package as a solution and not the entire offering surrounding the package, i.e. stability, vendor offering, product direction, etc. A mapping of package functionality, procedures and data-definition (semantics) usually suffices in this phase, resulting in a short list of potential packages. This process is better known as gap analysis and delivers the areas or issues that need be addressed if the business is striving for a total solution. The short listed packages have proven their suitability as an application solution, however no research or attention has been given to the suitability as a total business solution, i.e. the packages on the short list seem suitable only in isolation.
From the short list, each candidate package now has to be measured in context of the total vendor offering. Typically the applied criteria are things like supporting guarantees, vendor reliability, product direction, upgrading procedures, etc. Obviously, the offering yielding the highest performance in this exercise is selected and negotiated for purchase.
​
Of vital importance, however seldom performed, is to determine the package gap. A simple interface gap to a legacy investment could pose enormous development costs if, for instance, the technology to bridge the gap is not available in the market. True to the old saying of a chain being as strong as it weakest link, the package gaps need qualification.
Package Selection
Package Implementation
This almost always takes place in project-mode. The implementation team traditionally defines the project and business forfeits a substantial amount of control. The usual project management aspect is introduced and more or less governs the deployment of package functionality and modules as suited most comfortably to the implementers. The criticality of selected functionality is seldom addressed and is usually deployed in terms of the architectural inter-dependency of the package.
Phases in this project are conceptual designs, detailed designs, prototyping, acceptance testing and production. In most projects of this nature, the responsibility in terms of design resides with the implementation team who gracefully discards the business specifications after implementation.
Objectives, milestones and measurement objectives are defined from a resource management perspective and not from a business support view.
The package is implemented and users now have to gain proficiency in package use and maintenance. The vendors are best equipped for user training as all the product knowledge and training needs reside with them. Users are scheduled and receive training, again on the package in isolation. Ideally the needs of users in terms of the business should be incorporated in the training programme. The associated benefits would justify almost any investment in combined training; business awareness would be promoted, an understanding of the impact of user actions is gained and the package as support tool in the context of the business minimise individual threat.
User Training
System Building and Tailoring
This component of the methodology is required to address the following requirements:
-
Understanding business specifications.
-
Understanding technology implications.
-
Transforming business specifications into the required application specifications.
-
Mapping between the three architectural levels.
-
Data storage and maintenance.
-
Data retrieval and/or navigation primitives.
-
Ensuring business rules are embedded in the applications.
-
Information retrieval and presentation.
Organisation Restructuring
A method to deal with designing the ideal organisation structure for the execution of the new processes is required. A misaligned organisation structure could result in an inefficient business. Organisation structures could actually result in a business being constrained to certain strategies.
It implies that organograms cannot purely reflect the CEO’s historical experience or benchmarking flavours, or even his gut-feel or wishes. “Structure follows process”, therefore the new processes will be utilised to design the ideal organisation structures. All the potential influences on an organisation structure have to be accommodated and enabled to counter each other’s disadvantages.
A formal method is required to ensure that the most appropriate structure is implemented and supported by the workforce,
GAP Analysis & Vertical Integration
Measuring the discrepancy between what your business currently does and what it ideally should look like.
GAP Analysis
Measuring the discrepancy between what your business currently does and what it ideally should look like enhances your understanding of the severity of your current situation. The exercise of analysing the “GAP” should not be a time consuming exercise, and it should ideally cover all three architectural levels.
​
Gap analysis needs to be conducted at the three architectural levels to achieve three things:
-
Align the three architectural layers on top of one another.
-
Business Architecture.​
-
Process Architecture.
-
Process Architecture.
-
-
Ensure that they all enable the same strategic direction.​
-
Determine the effort required to bridge the gap, or the size of the gap.
Architecture
Perceived Current Situation
Future Enterprise Architecture
Testing & Implementation
In most projects a testing environment or sub-project is not established or neglected during the project-planning phase. Testing is something that not only applies to the latter phases of the project where information systems are implemented; it applies to any deliverable from the anticipated design of the business, to the last business concepts that are implemented.
Training
The focus of training in an organisation should be on the development of knowledge, skills and attitudes. The balance between these three characteristics is likely to reflect the nature of the change being managed.
​
Changes, which can be classified as “minor”, are likely to require knowledge-based learning, while those that are classified “major” are likely to require learning which focuses on changing attitudes.
​
Even the best solutions could result in failure, without the people who are executing them understanding their full potential or executing them incorrectly - they will simply not represent a solution.
Human Engineering , Organisation Behavior Consulting or Organisational Change Management
All change interventions are based on Strategic Repositioning of the business. This
enables focus and integration of all change initiatives. Business Architecture influences every plan. The deployment sequence of deliverables and the scope, content and context of sub-projects are mathematically determined. Any prioritisation of this nature causes uncertainty, perceived threat and resistance. Changes in Business Scenarios affect the direction, timing and prioritisation of these projects.
The participation and behaviour of the business workforce is exposed to elements not found in other projects. Business Engineering projects in particular enforce a particular structure on the workforce. ‘Structure enforces behaviour.’ It is possible to predict the behaviour of project participants and clients, due to the very specific threats, uncertainties, constraints, changes on the project parameters and rate of change in the business to which they are exposed.
Duration of change interventions within Business Engineering projects of this nature is implicitly longer. Longer projects are more exposed to changes on requirements. In Business Engineering projects the project as well as the employees have to adapt continuously to changes within the External and Target Environments of the business. The emotional side of any change, for example fear and trauma as a result of a procedural change due to new legislation, has to be addressed pro-actively in order to make the project succeed.
The change management challenge is to communicate the long-term direction that is going to be taken and to steer this change organisation wide. Ultimately each and every employee should commit him or herself to the change vision. Business Engineering Change should thus be managed in a deliberate way as opposed to following an emergent or opportunistic approach.
These factors imply, for Business Engineering Change Managers in particular, that an integrated technique set with that of the Business Engineer/ Architect, is vital for survival. The reality is that we operate in a treacherous, unforgiving business environment. A business solution is the end result of a multitude of multidisciplinary tasks; doing 999 of 1000 of them right does not guarantee a 99,9% success in the Business Engineering environment. Change management has an important role to play in ensuring a higher success rate in the task execution of the business engineering team, especially where culture, structure, quality and leadership seems to be a problem.
During a recent study, involving 150 Fortune 500 Company managers, three of the number one problems that were identified as obstacles in organisational management, were the following:
-
Communication
-
Lack of change acceptance
-
Weak leadership
​
Human issues have become a huge factor in business today, and the role of change management cannot be emphasised enough.
Repositioning of the business because of changes in the Target or External Environments.
Strategic Repositioning
Future picture of the
business’Target and External environments based on analysis and informed guesswork.
Business Scenarios
Changing the governance and mindset of the business.
Human Engineering
All factors that affects the business but cannot be affected back by the business.
External Environment
The environment where an organisation interacts with its clients, suppliers and competitors.
Target Environment
Business Engineering Programme & Project Management
Programme and project management of Business Engineering projects differ from the assumed philosophy of project management, ‘a project is something defined with a defined start and end’.
Because of the duration of Business Engineering projects the organisation’s external – and target environments could potentially change before delivery of the new solution. This implies we are attempting to hit a moving goalpost.
The project management has to ensure continuous navigation of the project within its own external – and target environments, as well as the navigation of the organisation to ensure it does not continue down a contradicting route. It must ensure that the project and the business end up on the same point at the same time.
Project risk management can be represented by the potential gap between the goal posts or destination of the project and the resulting direction of the business through the changes imposed by the project, in an organisation.
The required navigation of the ongoing business should always keep track with the project navigation in terms of delivering a successful project.
The size of the gap between these two routes (See shaded area) indicates the size of the risk associated with the project as well as the additional project effort to enable a successful delivery.
The twelve architectural components of the method set will dictate what we do in organisational behaviour as well as programme and project management.