Until now, we have planned our Strategic Initiatives and we have ensured that there are available resources with the required competences to perform the initiatives and deliver the expected results.
Strategy implementation is doing what has been planned in order to ensure that the Strategic Initiatives deliver the expected benefits to the organization.
The Strategic Initiative Teams know their roles and responsibilities to deliver the expected quality of all agreed results. They have the capacity to fulfill the roles and live up to their responsibility and objectives taking into account the conditions of the Strategic Initiatives.
If the conditions of the Strategic Initiatives change to such a degree that the foundation of the strategy needs to change, that is, a new base line is required, the teams have the tools to act and react fast.
The Strategy Governance Team with the Change Control Board and the Process Governance Teams all know how to initiate and perform PQA to improve Success Factors and change direction of the Strategic Initiatives if and when this is required.
However, how does the Strategic Initiative organization become aware of the need for change?
We need a method to ensure that each activity executed keeps its alignment with the corporate strategy under changing conditions such as:
• Leadership and management change their mind as the strategically aligned activities progress; this means that the activity implementation must be adapted to the new attitudes and maybe changed objectives.
• Initially expected resource availability does not materialize, which creates delays and quite often demands completely different processes to reach agreed solution quality.
• Perceived solution quality changes as key-stakeholders and clients change their mind and get wiser.
• Economic conditions change.
• Legal conditions change.
• The quality of delivered solution elements cannot be achieved.
• The involved resources cannot deliver within the set time frame.
The needed method can survey the conditions of all activities that are relevant to the executing Strategic Initiatives and the Strategic Initiatives to be initiated in order to discover:
• Sponsor and key-stakeholder attitude changes
• Risk conditions or events that have materialized and become problems
• Problems that were not foreseen
• Organizational changes with high impact on team performance
• Processes that do not deliver the expected quality of results
• Resources or organizations creating destructive conflicts
• Produced solution elements that are delivered for simulated Accept-Test with too many errors
The method that we have been using comprises the following elements:
• All Strategic Initiatives produce their results based on a requirements specification, which is sufficiently detailed to guide the Workgroups in their development, implementation, project management, and quality management work. The initial requirements specification will be referenced from the solution design, system, and user guide documentation.
• All Strategic Initiative work closes out with Accept-Testing that proves that the result complies with the latest version of the requirements specification, which is the one comprised by the latest baseline. The simulated Accept-Testing on milestone deliveries (sprints or use cases) ensures that the final Accept-Test reveals no new errors. You can compare this to the intermediate tests and the test flight that airplanes go through. The probability of serious errors found during final Accept-Test is close to zero. The documented result of the final Accept-Test is signed off by the sponsor once it has been approved by the involved Strategic Initiative managers.
• Communication:
• Progress measured by key performance indicators (KPI) that are explained in Chapter 6 on Strategy Governance.
• Deviations from baseline measured by KPI, but also measured by result quality, changed conditions, and pertinent events
• Strategy and Strategic Initiative evaluation with Process Governance Team and with Strategy Governance Team ensuring ongoing sponsor support
• Development of functional (error free) fully normalized databases and processes using agreed technology and ensuring the availability of a feasible information system operation and support. Solution design takes place here, but it is only documented for technical use in support of system operation and support, that is, it comprises technical details that the business users do not need to know about.
• Implementation of fully functional solution elements with availability of business operation support facilities and documentation such as user guides and training material.
• The solution design documentation is used for creation of Accept-Test documentation and business user guide production.
• Project and quality management ensure availability and efficiency of resources for development, implementation, and ongoing SAT of solution components delivered from development and implementation. Project and quality management survey and evaluate the Strategic Initiative progress primarily based on SAT results, but also looking after organization and process issues.
You can view the strategy implementation method from a continuous quality improvement point of view:
• Continuous quality improvement means that we decide to do something in the form of Strategic Initiatives to deliver required benefits, we initiate the initiatives by planning projects and programs, we do what we planned to do while adapting to conditions and events, we evaluate progress and results, and we restart the cycle with new decisions and PQA and so on.
• We have defined the basic quality object classes of Strategic Initiatives by which we can define and measure the stakeholder needs and requirements, when they are broken down into pertinent and measurable elements defined by a set of success factors classified into critical success factors (Figure 5.1).
FIGURE 5.1
Strategy quality object classes.
• The method elements that we use to perform continuous strategy quality improvement are the following(Figure 5.2):
• Process Quality Assurance (PQA) is used for team building, decision making, and planning.
• The Information Requirements Study (IRS) ensures that the scenario and the solution architecture are agreed to by key-stake-holders on all levels.
FIGURE 5.2
Continuous improvement of the strategy quality.
• The Object Lifecycle Analysis (OLA) defines and documents the detailed solution functionality designed by and agreed to by implementation and development stakeholders.
• Object-oriented functional design ensures an open system architecture that can be integrated with other open systems. The detailed normalization of data and processes ensure solutions that are robust to changing business conditions and requirements.
• Technical design embeds the systems in state-of-the-art technology while ensuring that common standards are applied across all solution elements to ensure the highest possible level of efficiency in construction and test.
• Tests on multiple levels of development based on agile principles ensure fast development, implementation, and adaptation to changed conditions and events. Final Accept-Testing only verifies that already well-functioning solution components work as expected in the future operating environment.
• Systems Management is ensuring the availability and correct functionality of the system seen from technical and business points of view (ITIL and COBIT compliant).
5.1 THE COFFEE BEAN STRATEGY IMPLEMENTATION METHODS
For strategy implementation, we will look at the method elements from a process point of view with development, implementation, and project and quality management that bring us all the way from the original idea and need for change to the final use and operation of the developed and implemented solution (Figure 5.3).
The idea behind the coffee bean strategy of simultaneous Development and Implementation coordinated by Quality and Project Management is to promote systems and lateral thinking and synergy leading to results that exceed the expectations of the stakeholders. It is an agile strategy.
The coffee bean strategy implementation process is divided into the three basic processes of any solution delivery:
• Quality (Project) Management
• Implementation
• Development
FIGURE 5.3
Coffee bean strategic initiative solution implementation.
The focus is on establishing agreement about what we actually do and deliver under the implementation of the strategy and the Strategic Initiatives once the program and project charters have been signed off.
Development, Implementation, and Quality and Project Management are made up of all required activities, processes, teams, and deliverables from initial formulation of the idea and business case to the final realization of the agreed solutions and their benefits, for example, strategy establishment and governance.
The coffee bean methods can ensure efficient strategy implementation and governance by:
• Offering agility-based processes that deliver measurable results and pertinent information for stakeholder communication supported by the Project Office and the Program Office.
• Usage of processes that are fully documented and easily understood by the involved participants and other stakeholders so that they can review and evaluate the results.
• Fast identification of deviations in cost, quality, scope, stakeholder attitude, and time of all expected results, which allows fast adaptation of the strategy to changed conditions.
The foundation for success with the coffee bean processes is that you visibly involve all relevant knowledge areas in the team building and in the scoping of the strategy with the strategy stakeholders such as we have seen in Chapter 2.
Regular periodic, situation-, and incident-based quality management (QM) activities such as SAT ensure that all decisions about activities, organizations, and deliverables are mutually accepted and signed off by the relevant stakeholders from idea to solutions in business use.
QM activities such as SAT and PQA ensure lateral thinking and synergy. Key development stakeholders meet key implementation stake-holders under (agile) PM/QM coordination in order to develop, test, and verify solution compliance with needs, to establish agreement, and to control progressive elaboration of the solutions to be delivered. This forum is detecting needs for change before it is too late to adapt the Strategic Initiative plans.
The simple agile principle of regular pertinent QM activities is quite often not adhered to, which is the reason for many conflicts and major program and project failures. Regular does not mean periodic unless you talk about a group of managers that meet every Tuesday for a round of golf. Regular in the context of strategy implementation means test and verification with short time intervals “when deliverable components are ready for verification by key implementation stakeholders.”
When you hear or read that the communication problems are the primary reasons for project and program failure, it is in most cases based on a lack of regular QM activities. Without these QM activities, you provoke serious risk such as:
• Sponsors do not understand the progress and lose confidence in the project.
• Baseline deviations occur without known reasons, so safe adaption to plans is not possible.
• Developers and Implementers get in destructive conflict.
• Important resources leave the project because they never get the solutions right.
We only measure progress by delivered solution components that have passed final Accept-Test.
We do not want to waste our time in QM meetings just to hear that “We progress well” or outright lies such as “We are 90% complete.” We have confidence in our teams and plans until the tracking shows that we are wrong and that we will have to act on deviations from the baseline. When these deviations from baseline occur, we know why and we are able to adapt in meaningful ways.
The QM activities ensure that solution, process, and organization fit together and that they are aligned with stakeholder expectations in both the long run and short term:
• The long run is defined by the duration of the strategy lifecycle (Benefits and Return on Investment and Equity are in focus).
• The short term is defined by the duration of Strategic Initiatives (project scope, deliverables, resource availability, time, and costs are in focus).
The coffee bean processes have been used with success to build a factory, to establish a cash card system, to control offshore oil production, and to swap all applications in a major private bank to name a few rather different program and project types.
Implementation comprises all the activities required to ensure that the stakeholders are happy with the solution in full use. The solution can be anything from a new organization, an atomic power plant, the power supply to a factory, a new car, a new bridge, a house, a TV program, or an information system.
Implementation activities comprise:
• Documentation of functional requirements
• Documentation of the outline solution architecture
• Verification of functional and legal compliance
• Preparation and use of Accept-Test scenarios
• Human resource training for use and solution support
• Accept-Test (Simulated and Final)
• Installation and test for operation sign off
• Short- and long-term solution support implementation
Development comprises all the activities required to make the delivered solution available in the quantities and capacities needed to meet the requirements of the stakeholders within the constraints of available and feasible “state-of-the-art” technology and other required resources.
Development activities comprise:
• Development and setup of information system software components
• Unit and integration test
• Validation of documentation of compliance
• Construction of a factory
• Construction of a solution component prototype
• Establishment of the development infrastructure
• Establishment of the operation infrastructure
5.1.3 Quality and Project Management
Quality and Project Management (QM/PM) comprise all the activities that ensure that development and implementation are coordinated and governed in such a way that the activities, processes, and their deliverables meet the expectations of the stakeholders.
QM/PM ensures that both long run and short-term expectations are met by establishing standards and measurable compliance criteria that can make it visible to all stakeholders that the strategy implementation progresses as expected and agreed to.
Communication, team building, decision making, and progress evaluation are essential QM/PM activities.
Other QM/PM activities comprise:
• Coordination of the development and implementation processes
• Simulated and final Accept-Testing
• Evaluation of and response to quality control results
• Documentation of agreement
• Governance support of the project scope and the business model
• Identification and involvement of stakeholders
• Establishment of the project administration with communication management
• Quality management activities
• Quality assurance activities
• Risk Management
• Change management for progressive elaboration
QM/PM ensures that all reviews and tests that are particular to the development process or to the implementation process are handled autonomously within these processes. This concerns development decisions about IT infrastructure and development tool standards, but also the unit and integration tests of a purely technical nature used for bug-free development of solution components. On the implementation side, it concerns the reviews of solution requirement specifications, user documentation, and training material. However, if in any of these cases help is needed from other stakeholders, QM/PM is there to arrange for that in the context of the “no excuse for failure” principle.
QM/PM approves the quality plan and the quality assurance activities in both the development and the implementation process; for example, QM/PM ensures that needed process standards, documentation standards, and open solution standards are available and used. In this way, QM/PM ensures that the involved stakeholders can interpret the results of quality assurance and quality control from any coffee bean process.
5.1.4 Simulated Accept-Testing
Development and Implementation activity is coordinated and aligned in Simulated Accept-Testing (SAT) workshops and through other efficient communication events.
Testing often on real-life solution components is an important part of agile QM/PM.
SAT brings people together from all relevant environments involved with current development, future usage, and cross-functional coordination of solution implementation.
Each SAT workshop covers a defined scenario and scope, where each SAT team member has a well-defined role to play. The objectives of a SAT workshop are defined to be SMART (Specific, Measurable, Agreed, Relevant, and Timed).
SAT makes it possible for the developers to present their solution to the future users and to explain why it is built the way it is. In this way, the SAT process opens up a positive discussion with the implementers and the future users about the quality of solution components.
The SAT participants look for and document required improvements that must be implemented, and they look for potential improvements to be evaluated for implementation by the Process Governance Team.
The open discussion among the SAT participants keeps all doors open; no one says never, only maybe or absolutely yes.
5.2 THE INFORMATION REQUIREMENTS STUDY
The IRS combined with the OLA is used for development of requirements specifications.
IRS documents where to go and how to get there by improving the organization, the information systems, and the corporate processes in light of the corporate strategic objectives and initiatives and the Success Factors established under PQA.
IRS techniques comprise:
• Establishment of a functional breakdown structure of the organization to be studied.
• Establishment of an IRS team to conduct interviews and consolidate the IRS result for Management approval; or, alternatively as we saw in the previous chapter, to facilitate and coach the business users in the development of Workflow-based requirements specifications.
• Selection of people to be involved with the IRS on three organizational levels:
• IRS Section Management or Workflow Workgroups
• Departmental Management
• General Management or Strategy Governance Team
• Interview and interview result documentation standard always asking and answering the pertinent why questions and defining the information objects that flow to, from, and within the IRS section. The Workflow requirements specification is a special version of this document, where the object flow is embedded in the Workflow documentation.
• OLA for IRS result consolidation uses action and structure objects found during IRS interviews to design the outline architecture of the solution to be developed and implemented. OLA is not used in the case of Workflow-based requirements documentation unless there are requirements for improvements to information systems and business processes that must be added to the existing solution architecture for it to be approved by the stakeholders.
• Recommendations with cost and benefit analysis.
IRS provides a foundation for definition of the necessary and sufficient information systems in support of the required business processes in the organization by revealing the information needs from all levels and functional areas of the organization.
The requirements definitions resulting from IRS address both information system-based and organization-based business processes and information concerned with the handling of:
• General management
• Resource management
• Sales orders
• Product development
• Production planning
• Purchase orders
• Accounting
• Logistics
• Customer support
The efficiency and the competitive power of the company are in focus when studying the performance of the business processes and their requirements for information in support of this performance.
The company’s IT supported information systems and its use of technology are outline designed under IRS as a solution architecture that can support the company’s business performance.
In the case of Workflow-based requirements specification, no outline solution architecture is designed when the Workflow requirements are used directly for solution setup and development in a COTS system that is supposed to be based on a normalized database and normalized processes.
It is fully possible to combine the outline solution architecture documentation with Workflow-based requirement specifications.
When not using Workflow-based requirements documentation, the IRS results in an IRS Consolidated report stating:
• Requirements for enhancements to current business functions
• Requirements for enhancements to current information systems
• Requirements for new information systems
• Required information system architecture
• Suggested development (procurement) of new information systems
• Suggested improvement to technology and IT organization
• Costs and benefits
IRS addresses current information systems problems by suggested enhancements. If the current information systems function well and if they are based on or can utilize “state-of-the-art” information technology, they will normally form part of the future information systems. If not, they will simply be replaced by new information systems. How surviving information systems are integrated with or form part of the future information systems is not within the scope of the IRS. The IRS will define the requirements for integration of information systems, not how it is done.
IRS documentation belongs to the business users who created and approved it supported by other IRS participants, IRS sponsors, and IRS facilitators.
IRS facilitators deliver a documentation standard that makes it possible to compare the study results directly with system analysis and system design documentation in reviews of these and for full traceability of requirements in the developed and implemented information system solutions.
5.2.1 Workflow-Based or Consolidated Report-Based IRS Documentation
When you plan the IRS process, you need to consider the situation of the organization that you will study:
• If the organization has required or developed a new information system and plans to merge its current business processes to be supported by this system, then an IRS Consolidated report is of no or less use because all information objects and their usage are already known. In this case, IRS will establish the organization to create Workflow-based documentation and to ensure a good quality of this for the setup and Accept-Testing of the new information system to be used, managed, and supported in the future.
• If the organization has the intention to improve business process information and information systems and if the organization has not yet purchased or developed a new information system for this purpose, the IRS Consolidated report production is the right choice for IRS because this IRS will allow the organization to choose a future information system solution that fits its needs for business process improvement.
• If the organization has a situation where both types of requirements to business improvements are relevant, then you can use a combination of IRS Consolidated report and Workflow-based solution requirements specification.
Irrespective of your choice of IRS process, the IRS organization building is the same. The different stakeholders simply have different responsibilities and roles.
Workflow-based documentation and IRS section report documentation has a common structure, but IRS with Workflow documentation does not produce management reports and consolidated reports.
The Workflow-based documentation is used directly by solution development and implementation Workgroups that implement the workflows as documented. This ensures business as usual or business conducted in a predefined way for legal reasons such as MiFID and Best Execution in the financial sector. This IRS method allows fast solution implementation if the available COTS systems or other IT-based systems can contain the required solution.
The IRS interview reports are consolidated in order to ensure a consistent solution development foundation with normalized databases and information system processes in support of the business processes involved in solution implementation.
This production of a solution architecture allows the development and implementation Workgroups to be creative during solution production and to deliver solutions that surpass the expectations of the stakeholders.
The normalization of data and processes from consolidation of the section reports supported by the management reports is the foundation for creating improved organization structures and improved communication to achieve the needed benefits of the Strategic Initiatives.
A Strategy Governance Team from the level of corporate leadership initiates IRS.
The Strategy Governance Team defines the objectives of IRS and establishes an IRS organization resulting from a PQA process or another decision-making process.
A feasible IRS organization comprises:
• The Strategy Governance Team that has defined the scope, the purpose, and the expected result of the IRS, and that has the power and the budget to allocate business participants and facilitators to the study. The Strategy Governance Team does not necessarily participate in the IRS study work, but it does sign off on the IRS Consolidated report.
• An IRS Workgroup with at least a project manager and a facilitator who establishes the groups to be interviewed (sections, departments, general management) for IRS report production. The IRS Workgroup schedules and performs the interviews and ensures that the interview report is written, approved, and accepted to be owned by the interviewed persons.
• In the case of Workflow-based requirements specification, the groups to be interviewed are replaced by Workflow Workgroups that produce the Workflow-based requirements specification. In this case, the IRS Workgroup facilitates and coaches the Workflow Workgroups with required documentation standards and reviews and formal training in Workflow documentation production.
• An IRS Reference Group represents the knowledge, competence, and experience across the business organization, which is needed for consolidation of the IRS sectional and managerial reports. The IRS Reference Group supports the IRS Workgroup to get the right people selected for participation in interviews and in reviews of resulting reports.
• In the case of Workflow-based requirements specification, the IRS Reference Group is the group of persons that manage the Workflow documentation production and that signs the Workflow documentation off for delivery to solution development and implementation. In this case, there is no IRS Consolidated report produced.
IRS is performed within the business user organization, but the IRS sections are most often a combination of business functional areas that together are necessary to produce a business result.
The traditional form of a business organization is the hierarchy dividing the managerial control of departments covering functional areas such as sales, production, finance, etc.
The market-oriented functional areas can be structured in divisions covering a specific product or a specific market.
The business organization structure is shown in Figure 5.4.
Some organizations are more development oriented than production and distribution oriented, for example, research institutions or dedicated research and development departments in major organizations. The operative areas in this case are most often organized in a matrix-shaped organization with departments/sections in one dimension and projects or products in the other dimension (Figure 5.5).
IRS participants are selected so they cover the necessary knowledge and experience concerned with the business information required by all the involved functional areas irrespective of the organizational structure of the organization to be studied.
FIGURE 5.4
Classical hierarchical business organization.
The IRS sections often comprise persons from several business sections in order to be able to evaluate cross-organizational information needs and complex business solutions.
A clue to the selection of business function representatives in IRS sections is to look for open-minded positively critical managers with three years’ experience in the studied organization or managers with comparative competences, that is, they know and understand the objectives and strategies of their organization, and they have a well-founded idea about how to reach these objectives.
Besides business process competence, IRS demands project management and method coordination delivered by the facilitator and the internal IRS coordinator, who plan and facilitate interviews, make sure that the right questions are asked, treat the answers with critical respect, and create at least the initial IRS results of sectional and management level IRS reports.
FIGURE 5.5
Matrix business organization.
FIGURE 5.6
IRS organization.
A long-term purpose of the IRS organization could be to be a forum for implementation of strategic improvements to business processes, organization, and information systems. It will be a group with a well-established set of methods for cross-organizational cooperation and implementation of business quality improvement (Figure 5.6).
The IRS organization comprises persons such as:
• General and executive managers and their deputies
• Managers from all user departments and their deputies
• Information system managers
• Project Office representatives
• Internal or external facilitators
• Project managers
The selection criteria for the persons are their method knowledge and experience (project manager and facilitator), their business knowledge, their competences, and their experience (information system managers, department/section managers).
The IRS organization can identify who in the organization possesses the knowledge and experience that must be revealed and documented by IRS. The IRS organization does not have to possess the knowledge themselves, it can be a big drawback if they mistakenly think that they do and on this basis write the requirements specification themselves because:
• The real owners of the future solution will refuse to take ownership of the requirements specification.
• Suggestions are passively accepted and pertinent disagreements are ignored instead of leading to better solutions.
The project manager and the facilitator perform the interviews on all organizational levels.
It is an advantage that some interview participants belong to more than one interview group in order to ensure good questions concerned with cross-organizational issues and needs.
In the case of Workflow-based requirements specification, there are no interviews; it is the project manager, the facilitator, and the IRS Reference Group that review and approve the Workflows for delivery to solution development and implementation. Also in this case, it is an advantage that some Workflow Workgroup participants belong to more than one Workgroup.
At least one IRS Reference Group representative should participate in a supportive role in all interviews if the project manager cannot fulfill this role. This representative is supposed to ask the questions not asked by the interviewers in order to get potential hidden facts revealed. He or she will also be able to resolve potential terminology differences between facilitator and IRS interview participants.
In the case of Workflow-based requirements specification, the IRS Reference Group representative will be managing the Workflow Workgroup.
5.2.3 The IRS Process to Produce the IRS Consolidated Report
The IRS process ensures that all possible viewpoints get involved in the study of information systems and information requirements.
The process starts on the sectional level, where business functions are performed for handling of the daily activities of the company.
The approved reports from the sectional level are passed on to the departmental and general management levels in order to prepare the managers on these levels as much as possible before they are studied.
The results from departmental management level are passed on to general management before this level is studied, but these reports are not shown to the sections unless so decided among the interviewed persons.
By following the bottom-up sequence, IRS provides all management levels with the best possible knowledge about the information requirements of the functional areas they control prior to their own participation in the study:
• IRS participants can focus on their proper level of information needs based on inspiration from PQA results and IRS reports from lower or the same levels of the organization.
• Newly appointed managers get to know the organization they manage better.
• Section participants are not constrained by higher management level expectations that they do not know about.
The consolidation of the sectional, departmental, and general management interview reports takes place in a forum comprising the IRS Workgroup and the IRS Reference Group that might have been augmented with new participants during the initial part of the IRS process. The IRS Workgroup and the IRS Reference Group participants divide the work of IRS Consolidated report writing among their participants.
The approval of the IRS Consolidated report and the recommendation it contains is done by the Strategy Governance Team, which might draw the last conclusion on a PQA workshop, where the IRS Consolidated report recommendation is an important input to an improved corporate strategy.
The IRS activities comprise the following:
• IRS is initiated by the Strategy Governance Team appointment of the IRS Project Manager and the IRS Facilitator. The IRS Project Manager and the IRS Facilitator are the IRS Workgroup. The initiation of IRS is often the result of an initial PQA process such as in the case of the military healthcare information system implementation that we will address further.
• The IRS Workgroup supported by the Strategy Governance Team defines the IRS sections. IRS sections are virtual organizational constructs that are required to produce one or more distinct products, which are used by other IRS sections or by parties external to the organization studied. Quite often, the sections selected for IRS interviews and reports will overlap with actual organizational sections such as Order Handling, Major Account Management, Engineering, and Dispatch. Together, the IRS sections cover all business activity in the studied organization.
• The IRS Workgroup establishes the IRS Reference Group of departmental managers to select managers to participate in sectional interviews. Each member of the IRS Reference Group gets the responsibility for one or more sections to be interviewed. It is this member’s responsibility to select the persons with the optimal knowledge and experience for interview. A reasonable size of a group for a sectional interview is 1 to 5 persons.
• Interview participant and reference group activation comprise seminars or meetings where the participants from all organizational levels in IRS are informed about what is expected from them and what benefits they and the company can obtain from a successful IRS. Participants in such meetings are prepared by a written introduction to the IRS process accompanied by any available PQA documentation.
• Sectional interviews focus on functions performed in the section and the information used in this context. The interviews result in a section specific requirement specification initially written by the facilitator. The approved requirement specification is formulated as if it has been written by the users themselves.
• Manager interviews and report reviews with the departmental managers and the general managers focus on decision making and the information required in support of this. Based on the dialogues and the business strategy view of the managers, the interviewed managers describe their visions and objectives for the business areas managed by the managers. The resulting IRS management reports are initially written by the facilitator, but it can be written entirely by the managers themselves.
• IRS report consolidation is an interpretation of all sectional and managerial IRS report requirement specifications. Report consolidation results in an IRS Consolidated report that comprises proposals for enhancements to business processes, organization, and information systems. A suggested development and implementation plan for solutions might be included, but such a plan is normally only produced after the IRS closes out in a new PQA process based on the IRS result.
• The Strategy Governance Team (the sponsor) approves the IRS Consolidated report. A PQA process can be used to define the conclusion as a short-term and a long-term implementation plan of the IRS recommendations approved by the sponsor.
5.2.4 IRS Process Duration Estimation
The duration of the IRS will depend on the number of interviews and the possibility of making the right resources available for the IRS. It is likely that the interviews result in requests for more interviews or new scenarios for planned interviews. It is therefore advisable to include some uncertainty in the plan regarding the total IRS duration.
The production of IRS sectional or managerial reports is estimated using a time box approach that limits the time used for interviews and report production:
IRS organization establishment |
5 days for facilitator and project manager |
Kick-off meetings—one meeting for each 4 interviews |
.5 days for all participants in interviews and reviews for production of IRS section and management reports |
Interview and interview review including sign off and delivery to the management level above |
8 hours for interview |
The value of the IRS section and management reports is not substantially increased by spending more time on the interviews and the report reviews because detailed description of business processes is not the purpose of the IRS unless Workflow requirements are produced.
IRS studies why the business processes exist:
• Their scope
• Their products
• Their purpose
• Their problems
• Their information requirements
• With whom they communicate
The production of the IRS Consolidated report takes 1 to 3 weeks depending on the number of interview reports to be consolidated, that is, depending on the complexity of the business studied.
The IRS Consolidated report as requirements specification allows information systems to be developed and implemented from scratch because it delivers a solution architecture that allows the designers and developers the freedom to create a solution based on state-of-the-art technological opportunities. In this context, the IRS Consolidated report caters to fast solution development and implementation without sacrificing the solution quality, that is, it caters to more satisfied stakeholders.
The IRS Consolidated report as requirements specification supports the choice and procurement of the COTS systems with the best possible support of the business processes in question.
The IRS Consolidated report solution architecture is an initial scope for COTS setup and COTS-based information system implementation, but it must be replaced by a Workflow-based documentation for final solution setup and implementation. The need for Workflow document production quite often surprises the user organization and leads to unexpected delay. If the Workflow documentation is done by the COTS vendor or an external turnkey solution provider, there is risk of very high cost overrun and delays because the user organization still has to be involved with analysis, reviews, and Accept-Testing.
Workflow Workgroup production of workflow documentation cannot be estimated using a time box principle. The estimation relies on talks with the competent resources to produce the workflow documentation. Only they can tell you how much time they need to produce documentation of the right quality.
The Workflow documentation standard that we presented in the previous chapter facilitates the work, but many other factors such as availability of competent employees, the experience of the project manager and the facilitator to coach the Workflow Workgroups, access to IT-based systems in test mode, and the number of business processes to be documented play a role here.
The Workflow example in the previous chapter that covered only one business functional area was produced in 2 months with very high priority supported by corporate management.
Workflow-based requirements allow relatively fast solution setup and implementation with COTS, but it does not leave much room for business process improvement.
5.2.5 IRS Participant Motivation
IRS participants are motivated to contribute with high quality information in interviews and reviews by giving them detailed information about IRS:
• Why IRS is performed the way it is
• How IRS is performed
• Why the participants have been selected to contribute
• How the participants can contribute
• The benefits to be obtained from the IRS result
The participant motivation assurance activity comprises:
• A workshop where all departmental/sectional managers are invited and introduced to the IRS process and its result. Here they are motivated to participate in the IRS Reference Group and to provide the best possible resources for IRS interviews or Workflow Workgroups.
• IRS kick-off meetings. All selected participants in interviews and Workflow Workgroups are invited to a kick-off meeting. The invitation explains to the invited participants that they have been selected to participate based on their knowledge and experience. Available PQA documentation concerning the IRS is included with the invitation.
• The kick-off meetings can comprise 15 to 20 persons each or a number corresponding to the persons to be involved in 2 to 4 weeks of interviews or to 2 to 4 Workflow Workgroups.
At least the first kick-off meeting should be opened by the sponsor (general manager or Strategy Governance Team member). It makes a strong impression when the kick-off meeting is opened by the sponsor who emphasizes the importance of the IRS and draws attention to the fact that the quality of the result depends alone on an active and committed contribution from the selected participants.
The kick-off meeting comprises a presentation of the IRS process and examples of the documentation that the participants will produce and take ownership of (coached by the project manager and the facilitator).
The IRS process is discussed and it is shown how this leads to a precise definition of the users’ requirements for information.
The kick-off meeting duration is 3 to 5 hours depending on the users’ motivation and their number of questions during the question and answer session following the presentation of the IRS process.
You should allow 1 week between a kick-off meeting and the first interview. The users are asked to consider the coming interview during this week. They need time to gather documentation and to prepare their requirements.
In the case of Workflow documentation production, the production can start once the kick-off meeting has closed out.
If this motivation assurance is not done, the participants turn up in interviews less prepared, which means that you get less information and in most cases low quality information leading to a long review process with more reviews. You might even get problems to make the interviewed participants take ownership of their report.
The interviewed persons in each IRS section have been informed in writing and in workshops how to prepare for the interview. They have prepared themselves for the interview by collecting supportive documentation such as reporting examples.
The dialogue in the interview is completely open. There is no questionnaire, but the interviewees know that their IRS section report comprises the following information about the section:
• Scope, purpose, and products of the section
• The purpose of the section’s functions
• What would happen if a function was not there
• Information used by the functions
• Information not available which would make it easier to perform the functions
• Information used from other sections and external parties
• Information being filed and maintained by the section
• Information given to other sections and external parties
• How the existing systems should support the functions
• Suggested improvements of information systems
• Suggested integration between IT-based information systems
• Expected benefits from enhanced and integrated IT-based information systems
• Suggested integration between IT-based information systems t Expected benefits from enhanced and integrated IT-based information systems
• Expected benefits from enhanced and integrated IT-based information systems
The section interview uncovers typically 2 to 5 important functions each comprising a number of detailed procedures. The detailed procedures are not analyzed during IRS interviews. Workflows for these procedures will be developed under information system design after the IRS Consolidated report has documented the IRS recommendations. Some procedures might not continue and new procedures might be established based on IRS.
Based on the interview, the facilitator writes the first suggestion for the IRS section report. Before closing out the interview, the facilitator should offer the interviewed persons an opportunity to write the report themselves because they will own the report irrespective of who has written it. Normally the report writing is left with the facilitator. It is important to explain to the interviewee that it is not the facilitator’s role to be responsible for the user requirements specification. The facilitator only shows examples and defines a document standard to be used when working out the section report while the users write the content directly or indirectly. The interviewees own their IRS reports.
The user interviews can be extended to or supported by workshops where the interviewees get the opportunity to work with the elements of the IRS documentation in a facilitated environment.
When the interviewees have approved their section report, it is delivered to the IRS Reference Group for final approval. The IRS sectional report is transferred to the departmental managers who are responsible for the section concerned.
The section reports are used as a basis for the department managers’ description of their information requirements. The department managers often regard the functions of the sections in a different way than the persons interviewed. This is because the functions are performed in view of an operative environment, of which the department manager does not necessarily know all the details.
The department manager’s point of view will be influenced by the manager’s affiliation with a specific business area such as finance or production. The section reports for this area compared with the manager’s ideas and objectives can result in conflicting wishes between sections and department managers.
The conflicts can form the basis for organizational or administrative changes to be carried out in order to utilize the information systems in a better way or simply to enhance the performance of the department and the sections.
To let one of the parties dominate the conclusion is seldom a desirable situation. This is one of the main reasons for starting the IRS on section level without pre-defined limitations in relation to the department manager’s point of view.
The facilitator is responsible for the department manager’s report complying with the required document standard for this report. The content of the management report is the responsibility of the department level manager and is quite often written by him or her.
Section reports and department reports are complemented with a top management report written by the general manager. The facilitator is again responsible for the report structure, but contrary to the departmental managers, the executive manager quite often wants the facilitator to write the executive level management report. This gives the executive manager an opportunity to understand how the project manager and the facilitator interpret the executive’s needs. In this way, he or she can criticize the program manager and the facilitator, which he or she should, and not the other way around.
The executive manager (or the Strategy Governance Team) is interviewed on equal terms with the department managers. It is important that the general manager’s report is treated as critically as the other reports with regard to structure and content—it is particularly important that the overall objectives of the company are described briefly and precisely in this report.
The IRS manager interview reports have the following content:
• Scope, purpose and products
• Requests for improved information
• Potential improvements of the basis for decision making
• Expected value of improvements
Departmental manager reports are approved by the interviewed managers and transferred to the executive managers before these executive level managers are interviewed.
5.2.8 IRS Report Consolidation
When all sectional and managerial IRS reports have been approved, we are ready for the consolidation of the sectional and management interview reports.
The complete IRS organization handles the consolidation of the IRS reports. The IRS organization establishes one or more workshops for final definition of the common terminology and the objects to be used for handling business processes and communication. The IRS consolidation workshops can be done over 1 to 3 weeks, where the duration of each workshop is dependent on the number of interview reports to be consolidated and the number of objects found.
It can be an advantage to have 2 to 3 consolidation workshops with 3 to 5 days between each workshop. This allows the participants to review the conclusions and ideas with colleagues and other knowledge bases between workshops.
In the Defense Healthcare Case, we used five days for one workshop to produce a very comprehensive IRS Consolidated report to be used for procurement of an appropriate information system. In this case, the initial consolidation preparation by the project manager and the facilitator was comprehensive.
Before the IRS consolidation workshops, the facilitator supported by the project manager prepares the consolidation:
• All objects that are the same object, but which belong to different sectional reports and sometimes have different names, are grouped together. A standard object description form is used to define the name, the key, and the reference keys of these objects.
• Each chapter in the sectional report is grouped together with the same chapter from other sectional reports. The resulting cross-section of chapters (with their section ID attached) shows exactly how functions, requirements, problems, and suggested solutions are distributed over the studied organization.
• The cross-section of the input/output chapter is checked for consistency across sections (i.e., what one section delivers to another section should be received by that other section).
This consolidation support material is distributed to the IRS organization before the workshop.
In the consolidation workshop, all inconsistencies and suggestions are discussed. The commonly accepted conclusions are documented in a memo or in minutes from the workshop written by the project manager and the facilitator.
In order to ensure that all IRS Consolidated report writers and reviewers use the same basic terminology and interpret the terms in the same way, the consolidated objects and terms prepared by the project manager and the facilitator are reviewed and approved.
The common terminology and object definitions are documented in standard documents:
• Vocabulary
• Object description
The new consolidated objects are classified into:
• ACTION objects
• STRUCTURE objects
The action objects describe all information needed for performing “time-stamped” actions such as receiving an order, calculating an order, producing to an order, packing an order, or dispatching an order. The ORDER object could cope with this task, but there could also be a PICKING object covering several orders and a SHIPPING object covering several PICKINGS and ORDERS in order to clarify the actions and their interrelationships fully.
For each action object, we want to understand all information needs of each process of the functions handling it and the functions depending on it. Much of this information is kept in structure objects that define INVENTORY, CUSTOMER, PRICE/CONDITIONS, DELIVERY CONDITIONS, and PRODUCT.
The interrelationships between processes and objects are shown in Object Lifecycle Matrices (OLM). The OLA (Object Lifecycle Analysis) establishes the OLM. The OLA technique is also used for data and process normalization in detailed solution design, which is not within the scope of IRS.
For the purpose of IRS consolidation, we perform OLA for high-level functions in order to be able to outline one feasible and complete solution architecture, not for detailed information system design.
An OLM for the ORDER object is shown in Figure 5.7.
The OLM shows for each action object studied what functions are handling it and what other objects are needed by the function for this performance. All of this information is also available in text in section reports and the consolidated report, but the text is less easy to understand than tables and graphics.
The structure of the consolidated report is defined during the Workshop and the responsibility for writing each chapter is assigned to the members of the IRS organization.
FIGURE 5.7
Object Lifecycle Matrix.
The project manager and the facilitator coach the writing process and ensure that written chapters are distributed to the other members of the IRS organization in time before the closing review.
The IRS Consolidated report is finished by the IRS organization in a consolidation-closing workshop of 1 day’s duration.
The IRS Consolidated report documents the information requirements in support of both operative functions and management decision making on all levels of the organization. It shows how the requirements can be fulfilled by a combination of improved business behavior and improved information systems.
The IRS Consolidated report is delivered and introduced to the sponsor at a meeting. After the meeting, the sponsor needs a week to read the report before it is discussed for approval with the IRS organization in a more structured meeting.
The approved IRS Consolidated report belongs to the sponsor. During IRS, we have produced:
• PQA-documentation and the Activity Description concerned with IRS
• The IRS organization
• Sectional reports with supporting graphics and tables:
• Object descriptions
• Data Flow Diagrams (DFDs)
• Entity Relationship Diagrams (ERDs)
• Vocabulary entries
• The IRS Consolidated report
• List of Action objects and Structure objects supported by graphics and tables:
• Cross reference tables
• Input/output tables
• Object lifecycle matrices
• Common object descriptions
• DFDs
• ERDs
• Common vocabulary
• Consolidation memo/minutes
• Reviewed or new PQA-documentation
Once the IRS Consolidated report has been approved by the Strategy Governance Team (sponsor), they can get together for a PQA workshop, where new visions, missions, success factors, and future Strategic Initiatives to follow up on the recommendations of the IRS Consolidated report are established.
5.2.10 The IRS Consolidated Report
The IRS Consolidated report does not form an adequate basis for detailed process descriptions and object definitions, but it makes it possible to describe an outline structure of the needed database content and an outline system architecture, which satisfies the users’ requirements for information and functionality in future information systems and business processes.
During the IRS consolidation workshops, several possible conclusions will be evaluated and discussed. The possible conclusions are based on the cross-sectional requirements selected from each sectional report and supported by the management report information.
Only conclusions that are agreed to or which cannot be debated are stated in the IRS Consolidated report. These conclusions can further be listed in a memo or minutes from the IRS consolidation workshops.
Personal conclusions can be listed as ideas for later debate with the Strategy Governance Team (sponsor), which can approve these conclusions for inclusion in the consolidated report or reject them.
A common IRS Consolidated report structure is suggested here:
1 |
Introduction |
1.1 |
Introduction to why and how the Information Requirement Study was conducted |
1.2 |
The IRS organization with sponsoring Strategy Governance Team |
1.3 |
The Analyzed Organization (visions, objectives, critical success factors, products) |
1.4 |
The section structure used for sectional interviews |
1.5 |
Summary (What can the analyzed organization obtain from improved information systems and business processes?) 2 The company’s Information System Situation |
2.1 |
Identified Information System problems |
2.2 |
Requirements to the future Information Systems 3 Business area Information System requirements by business area (not section) |
3.1. |
General management area |
3.2. |
Production and logistics area |
3.3. |
Customer service area |
3.4. |
Product development area |
3.5. |
Financial control |
3.6. |
Personnel and administration 4 Proposal for future Information Systems |
4.1 |
Information system opportunities and their possible impact on business areas |
4.2 |
Technology opportunities and the potential impact on business areas 5 Conclusion |
5.1. |
Recommended Information Systems |
5.2. |
Recommended future handling of the Information Systems environment (organization, technology, method, techniques and tools) |
5.3. |
Recommended Information System Implementation Plan (organization, risks and quality management) |
5.4 |
Expected benefits and costs |
An outline of a real-life example of a consolidated IRS report is shown in Appendix F.
5.3 THE OBJECT LIFECYCLE ANALYSIS
OLA is used for consolidation of the IRS into a solution architecture that is used during development, implementation, and quality management of the solution components.
The following citation shows why we are using objects and entities in the same way. The entity approach or the extended entity approach is best used for normalization, while the strict object approach is strong when it comes to openness and integration design, and we need both:
The extended entity-relationship (EER) model is being “threatened” by the object-oriented (OO) approach, which penetrates into the areas of system analysis and data modeling. The issue of which of the two data models is better for data modeling is still an open question. We address the question by conducting experimental comparisons between the models. The results of our experiments reveal that:
a) Schema comprehension: ternary relationships are significantly easier to comprehend in the EER model than in the OO model.
b) The EER model surpasses the OO model for designing unary and ternary relationships.
c) Time: it takes less time to design EER schemas.
d) Preferences: The EER model is preferred by designers.
We conclude that even if the objective is to implement an OO database schema, the following procedure is still recommended:
1) Create an EER conceptual schema,
2) Map it to an OO schema, and
3) Augment the OO schema with behavioral constructs that are unique to the OO approach.
Source: Shoval, P. Experimental Comparisons of Entity-Relationship and Object Oriented Data Models. Australasian Journal of Information Systems, Jul. 4, 2007.
We use the EER approach to design and normalize the databases, and we use the relatively simple DFD to show relationships between processes. Our OLM is the textual basis for the DFD.
The solution developing Workgroups continue to use OLA for detailed system design, but here it is combined with agile prototyping, user interface development, distributed solution components development, and simulated Accept-Testing.
The OLA ensures that processes and data are normalized for object-oriented development that ensures integrity and validity of developed solution components in all use scenarios. This method is independent of technology and distribution of functionality. It is used to ensure normalization and integrity of the solution. Once normalization and integrity is ensured, you can distribute the functionality to web, cloud, communication equipment, servers, or portable equipment in search of the best performance.
The distribution of the solution does not change the basic normalized, valid, and consistent solution, it just makes it accessible where data can be handled the best possible way and it makes the solution more user friendly.
Open solutions based on normalized data and processes in standardized IT environments are easy to adapt to new technological and business-based requirements and equipment, and they are easily integrated with other applications such as free and open web services if they are documented with a view to adaptation and integration.
The Defense Healthcare Solution is a good example of this value from OLA. The recommendation is distribution of functionality in order to be able to capture and validate the data with a minimum of human interference, and to be able to use the complete set of data needed in a function that is located geographically distant from the different databases that supply the data.
Relationships of different kinds are defined more precisely by a matrix than by textual descriptions or even a diagram. This is especially true if there are many “variables” in the relationship. If you want to show the complete pattern of communication between all sections of the organization, you might want to use an input/output matrix showing for each section along the horizontal axis from which sections along the vertical axis it obtains its information expressed in objects/entities, or reports (Figure 5.8).
The OLA matrix and the PQA matrix are other examples where matrices are necessary to show the full overview of multiple relationships.
Various drawing techniques can be used to visualize complicated interrelationships between functions, between entities/objects, and between functions and entities/objects.
I recommend using diagrams and matrices whenever possible because they give a much better overview of complicated situations than even the most precise and well-formulated text. With matrices, it is much easier to check for completeness of relationships such as you have seen with the risk response matrix and the input output matrix.
FIGURE 5.8
Input output matrix.
Figure 5.9 Data Flow Diagram drawn with SILVERRUN.
Diagrams do not answer the why questions, but in most cases they can illustrate the how. Diagrams do not replace text, they make the text more readable.
The relationships between functions and objects can be shown in DFDs. Please be careful not to complicate the DFD with too many processes and objects. Complex structures are better broken down into small, interrelated diagrams, where each diagram tells a partial story (Figure 5.9).
The relationships between objects can be shown in ERDs. The ERD has the action object in focus and the number of entities should be limited to a selection that is easily understandable (Figure 5.10).
Relationships between structure objects are more often of a parent/child type, where one object inherits information from another one, for example, CUSTOMER inherits the account number from the DEBTOR, and CUSTOMER WAREHOUSE inherits customer name from the CUSTOMER giving the relationships shown in Figure 5.11.
In order to understand all implications of a delivery to a warehouse, one needs information from both customer and debtor. Inheritance and relationships showing, for example, the customer types that constitute the customer object are better described using structure charts such as shown previously.
FIGURE 5.10
Entity Relationship Diagram drawn with SILVERRUN.
The diagram in Figure 5.10 tells a story:
* The Underlined item is the primary key
* The items marked with FK are foreign keys, i.e. Reference keys
* Material has zero or many Order lines and Deliveries
* A Client has zero or more Orders
* Orders and Material can be split on many deliveries.
FIGURE 5.11
Hierarchical inheritance data model.
Two case studies have been included to illustrate the IRS process and the IRS results:
• The Defense Healthcare IRS Consolidated report
• A private bank sectional report
5.4.1 The Defense Healthcare IRS Consolidated Report
The setup of the Defense Healthcare IRS organization and the preparation of the study with PQA have already been shown in Chapters 3 and 4.
The sectional breakdown structure and the development of the IRS Consolidated report are shown in Appendix F, where the IRS Consolidated report structure is shown and explained.
In the consolidated report, the process to produce the report is described. The sectional and management reports followed exactly the guidelines in Appendix E, but the actual reports are not shown, only the guidelines.
5.4.2 The Private Bank Sectional Report
The private bank sectional report is shown as Appendix G.
5.5 SOLUTION DESIGN AND DEVELOPMENT
Solution design and development are the original subjects for agile behavior. To create agreement between designers, developers, and solution demanding users has always been a challenge for several good reasons:
• The demanding users have not always been able to describe their needs in sufficient detail for the developers and designers to create and deliver what the users want.
• The designers and developers have created solutions that are closer to their technological constraints and opportunities than to the business functionality demanded by the users.
• Solution requirements reviews have been conducted without design and development involvement leading to wrong interpretation of the user demands and a lot of wasted time and money to develop unacceptable solutions.
• The users are too busy to be involved in satisfactory solution Accept-Testing leading to situations where serious errors are discovered under system usage.
We have already seen some methods and tools that can help overcome these problems:
• PQA and team building ensure a safe foundation for establishing agreement about the Strategic Initiative Success Factors.
• IRS with initial PQA establishes a requirements specification for solution development and implementation that fulfills the PQA Success Factors.
• Post-IRS PQA establishes the best possible teams for solution component procurement, development, and implementation.
• OLA with text-based and graphical solution documentation elements offers an opportunity to create easy to use and easily understandable detailed design documentation to be used by both IT experts and solution users.
• The OLA method offers an opportunity for data and process normalization that is required for solution integrity and consistency assurance.
• Workflow-based documentation with access to user interface documentation is a sufficient tool for IT supported solution creation.
While it is relatively easy to get the solution users and their management involved when starting up Strategic Initiatives with PQA, it is increasingly difficult to get the users motivated and committed during solution development and implementation.
Already under the IRS-based solution architecture development it becomes difficult to get the users motivated and involved. Some users fear the future and others are too busy doing their job to play a role in IRS. They participate in interviews because they are asked to do so, but they do not want to write the interview reports or take committed ownership. The users are very often dissatisfied with interview reports written by an IRS facilitator who needs time to understand the users’ unspoken requirements—the unknown knowns that all the users know so well that it is not necessary to write them down.
When we arrive at detailed solution design and development, there is no limit to the unwillingness to participate from the business user side. A good example is the private bank system swap that was close to ending up a flop because the business users had no confidence in the development and implementation project—with good reason.
It is because of this natural suspicion and lack of motivation that Strategic Initiatives require that special attention be made to the business users:
• They are coached to produce their requirements with high quality from business procedure improvement to information system solution implementation. High quality means that they are proud of their contribution and take ownership.
• Their involvement is kept to a minimum because they are driving the business that earns the profit to pay for the improvements.
• They are involved in activities that promote their motivation and willingness to participate in the Strategic Initiative.
• They are motivated to participate in activities where their knowledge is absolutely needed by proving to them that no solution can be delivered without their contribution.
In order to protect and support the business users as best as possible, we involve them only when we want them to evaluate finished and technically error-free solution components supposedly responding to their real business requirements and expectations.
The only moment where this is not true is during the IRS interview, where we all start from scratch with the exception of the IRS Reference Group and the users themselves. This process is highly risky and that is why we make a big effort to inform the users about what we expect from them.
This respect for the users and their business work priority is part of the agile principle. When we involve people, we do it in processes where they implicitly will understand that their opinion and judgment counts.
During solution design and development, we leave the object orientation and the normalization with the experts and we depend only on the users to accept their own part of the solution. This happens during simulated Accept-Test and under final Accept-Test.
In the meantime, we use members from the IRS Reference Group and the IRS Workgroup to work directly with the solution designers and developers to develop the solution components ready for installation, operation, and Accept-Test. This is the forum for the original agile principles, but the agile principles also hold true during simulated Accept-Test.
Only completed and technically error free solution components are delivered for Accept-Test.
The design documentation is structured by the system components structure. It explains how process and data normalization have been implemented. This corresponds to what you can expect from a COTS vendor user guide before the COTS system has been adapted to your business specific information system needs.
This documentation is produced by the solution designers and most often by the database designers among them.
The IRS Reference Group and the IRS Workgroup produce the training documentation and the training Workflows. Contrary to the user guide, it contains complete business procedure use case Workflows with training data. There is often one set of training material for each type of business solution user, for example, one for the front office and another one for the back office.
5.5.3 User Guide Documentation
The user guide is structured according to use cases. The user guide documents the exact Workflows with user interface interaction and data validation rules that produce the users’ business solution results as required.
SAT is used for meaningful involvement of the future users of an information system solution.
SAT allows the involved parties to verify that their business workflows are fully supported within the scope of the tested solution components.
SAT is performed with intervals of 2 to 4 weeks during the development and implementation of business solutions. The conditions for SAT of a solution component are:
• The solution component works technically and is robust for most thinkable user errors, that is, it works as designed and gives nice error messages when users treat it differently than expected.
• The technical infrastructure works when the users arrive for testing and it continues to work while testing except from unexpected but possible IT breakdowns. It has been ensured that the users can log on to the solution and use it as designed, for example, no one has touched the firewall settings overnight.
• Support from IRS Reference Group and Workgroup and from COTS or other system developers is available in the SAT environment.
• The users have been educated in the usage of the solution component for SAT and they have approved the training material with recommended improvements (on the SAT Issue list). In this way, the involved users know what they can expect.
• The user guide for the solution component is available, but it is not the SAT testers outside the IRS Reference Group and the IRS Workgroup who recommend changes to this document.
• The technical developers have presented the solution and its strength and eventual issues in a presentation in connection with the Accept-Test user training.
• Aside from structured business process oriented SAT test cases that the user is obliged to use first, the users are also requested to test other usage opportunities of their own choice. Sometimes this gives surprising results that can improve both the technical and the business functional solution.
• Error and Issue reporting document standard is available and is filled in by the IRS Reference Group and the IRS Workgroup participants immediately when an error or issue has been discovered. Error descriptions are further copied to the developers for handling.
SAT testing is regression testing because the SAT is repeated until no usage blocking errors are found. Each regression can comprise more functionality, not just corrected functionality.
Test models and testing could easily be a subject for another book, so here I will just outline a few principles for a SAT checklist.
Unit testing and integration testing during system development are left with the developers and designers. They simply have to deliver error-free solution components for SAT. All other developed solution elements are of no interest to SAT. This is the agile principle and the foundation for agile tracking of progress.
The developers, designers, and the IRS Reference Group and Workgroup have established the sequence of solution modules (use cases) to be created and delivered for SAT.
I recommend using a system such as HP Quality Manager to keep track of your SAT plan and the SAT progress. When a solution module has passed SAT, it is ready for final Accept-Testing. If a solution component that has been approved from SAT is changed for some reason, it is SAT tested again, eventually together with other SAT ready solution components. This is the “regression testing” principle.
SAT test model checklist:
• Use a test management application to keep track of the test progress.
• I have used HP Quality Manager with good results.
• The test cases cover all business procedures from end to end.
• Test data, especially structure objects, allow for all result and procedural variants to be tested.
• Document exactly the expected results in the test case Workflow document.
• Enumerate the test cases and register them in the test management system. Personally, I document the test Workflows outside the test management system, but it is up to you how you want to do it.
• Make sure that an error is not based on a test document writing error before you report it.
• Make sure that all test cases are at least outlined in the training material to be used for SAT user introduction to SAT.
• Personally, I register test results outside the test management system, so that this system only tells the users who have tested, what has passed, and what has not passed. Again, it is up to you to decide how you want to handle this.
• Make sure that you have an Issue and Error documentation standard and use it. Issues and Errors are tracked for resolution, for example, such as shown in the next section.
5.6.2 Test Result Documentation
The test is documented with a sign-off sheet that lists what has been tested by whom and what the result was. Attached to this sheet is the test result documentation with error and issue list.
A SAT test can declare a solution module ready for use even though less important issues and errors are outstanding.
For test result documentation, I propose the following standards:
• An error and issue tracking document
• An error and issue description document that allows tracking the error or issue to its source, or even its reason if possible
The document standard that I have used for error and issue tracking is an Excel spreadsheet with the following columns for each error or issue:
• Error or Issue ID that interfaces to the Error and Issue description document
• SAT date
• Urgency (IMMEDIATE CORRECTION, NEXT PATCH, NEXT VERSION)
• Severity (A Blocking, B Major, C Minor)
• Status (NEW, ANALYZED, PENDING, FIX SCHEDULED, SOLVED, VALIDATED, REJECTED)
• Status date
The error and issue description document is shown in Figure 5.12.
5.7 FINAL ACCEPT-TESTING AND SIGN OFF
The final Accept-Test is a mere verification that the solution is ready for use. There are no formal test cases except for the ones used for SAT.
FIGURE 5.12
Error or issue document.
The solution might go into production with errors and issues still open, but only issues and errors that have no influence on the integrity, validity, and consistency of the solution.
The developers, designers, the IRS Reference Group, and the IRS Workgroup sign off on the accepted solution delivery.
The sign-off document with outstanding errors and issues is stored for reference.
5.8 SOLUTION OPERATION KICK-OFF
Solution operation kick-off is a champagne party with high attention from the future support organization that will be responsible to keep the users happy until new changes are introduced.
If the sponsor does not pay for the champagne, you have a problem.
Strategy implementation is doing the right things at the right time in the right sequence in order to ensure that the strategy gives the expected benefits to the organization.
You can view the strategy implementation method from a continuous quality improvement point of view.
The coffee bean methods can ensure efficient strategy implementation and governance by:
• Offering agility-based processes that deliver measurable results and pertinent information for stakeholder communication supported by the Project Office and the Program Office
• Usage of processes that are fully documented and easily understood by the involved participants and other stakeholders so that they can review and evaluate the results
• Fast identification of deviations in cost, quality, scope, stakeholder attitude, and time of all expected results, which allows fast adaptation of the strategy to changed conditions
The truth is that things never turn out the way we planned them unless we adapt our plans to what we actually do and produce. Communication is crucially necessary here.
We measure progress by delivered solution components that have passed final Accept-Test only. We do not want to waste our time in QM meetings just to hear that “We progress well” or outright lies such as “We’re 90% complete.” We have confidence in our teams and plans until the tracking shows that we are wrong and that we will have to act on deviations from the baseline.
The QM activities ensure that solution, process, and organization fit together and that they are aligned with stakeholder expectations in both the long run and the short term.
Implementation comprises all the activities required to ensure that the stakeholders are happy with the solution in full use.
Development comprises all the activities required to make the delivered solution available in the quantities and capacities needed to meet the requirements of the stakeholders within the constraints of available and feasible “state-of-the-art” technology and other required resources.
Quality and Project Management (QM/PM) comprise all the activities that ensure that development and implementation are coordinated and governed in such a way that the activities, processes, and their deliverables meet the expectations of the stakeholders.
IRS documents where to go and how to get there by improving the organization, the information systems, and the corporate processes in light of the corporate strategic objectives and initiatives and the Success Factors established under PQA.
The IRS provides a foundation for definition of the necessary and sufficient information systems in support of the required business processes in the organization by revealing the information needs from all levels and functional areas of the organization.
A clue to the selection of business function representatives in IRS is to look for open-minded positively critical managers with 3 years’ experience in the organization or managers with comparative competences, that is, they know and understand the objectives and strategies of their organization, and they have a well-founded idea how to reach these objectives. A long-term purpose of the IRS organization could be to be a forum for implementation of strategic improvements to business processes, organization, and information systems. It will be a group with a well-established set of methods for cross-organizational cooperation and implementation of business quality improvement.
OLA is used for consolidation of the IRS into a solution architecture that is used during development, implementation, and quality management of the solution components.
For the purpose of IRS consolidation, we perform OLA for high-level functions in order to be able to outline one feasible and complete solution architecture, not for detailed information system design. The IRS Consolidated report documents the information requirements in support of both operative functions and management decision making on all levels of the organization. It shows how the requirements can be fulfilled by a combination of improved business behavior and improved information systems.
The IRS Consolidated report does not form an adequate basis for detailed process descriptions and object definitions, but it makes it possible to describe an outline structure of the needed database content and an outline system architecture, which satisfies the users’ requirements for information and functionality in future information systems and business processes.
The design documentation is structured by the system components structure and explains how process and data normalization have been implemented.
The user guide documents the exact Workflows with user interface interaction and data validation rules that produce the users’ business solution results as required.
A SAT workshop covers a defined scenario and scope, where each
SAT team member has a well-defined role to play. The objectives of a SAT workshop are SMART (Specific, Measurable, Agreed, Relevant, and Timed).
SAT allows the involved parties to verify that their business workflows are fully supported within the scope of the tested solution components Unit testing and integration testing during system development are left with the developers and designers. They simply have to deliver error-free solution components for SAT. All other developed solution elements are of no interest to SAT. This is the agile principle and the foundation for agile tracking of progress.