Introduction
This article tells the story of a Business transformation in a financial organization of moderate size. This Client Organization decided to outsource most of their IT activities – lock, stock and barrel – to an External Provider. Outsourcing was a management decision. Business Control (the Information Management department involved with supporting Business processes and handling Demand and Supply of changes in information systems and infrastructure for the Client Organization), was not involved in decision-making; it just happened and a date was set at which future IT operations should be provided by the External Provider.
This article outlines the way business transformation took place as seen through the eyes of the Business Analyst and his counterpart, the SPI expert implementing new processes, modifying roles and organization structures to support the transformation to a future mode of operations.
Transformation
The External Provider had a great deal of experience in business transformation programs for organizations. To support outsourcing (Back-Office part of) IT operations of the Client Organization, the External Provider used his own standard approach. Negotiations took place with the Client Organization, a price was set and practical things such as a contract, transfer of people and usage of facilities were developed and agreed upon. The External Provider first set up an organization structure to address step one of transformation, the required transition of current IT activities till reaching a steady state. The External Provider brought in a transformation team of various specialists such as: contractual specialists, estimating specialists, ITIL specialists (operational support), knowledge management specialists, and process improvement specialists. These SPI specialists were engaged in customization and implementation of all IT and Business/IT processes: SDLC, maintenance and (Technical) Support including project delivery and release management. Transformation was step two of the business transformation. Goal was end-to-end standardization of processes and alignment of tools and reducing the price of delivery by going offshore.
Organisation
All IT staff of the outsourced IT department, sub departments including the IT Development and Test Services, together with their line management, was the object for business transformation. They were appointed to leave the Client Organization and enter the External Provider organization. A transition period was planned to identify the needs and requirements to transform current IT processes, people and facilities to the External Provider. After completion of the Transition phase, IT business operations ´as-is´ should be ready to be supported by the External Provider; at first on site the Client Organization, later on to be transferred to onshore within the External Provider. Real transformation was planned to take place after completion of Transition, a period in which changes and improvements should be implemented in a way the External Provider should be able to support business operations at the target level as specified in the outsource contract.
Outsourcing IT meant that a split had to be made in the IT department. This also affected Business Control, sub department of the Client Organization working as an intermediate between Business and outsourced IT. Soon it was apparent to Business Control that the split affected more than people, processes and facilities; organization structure, roles, knowledge, responsibilities, access control to systems and physical housing had also to be addressed.
Current state – As Is
For tens of years the Client Organization was in the habit to work quite informally with their internal IT department. People knew each other for quite some time. Knowledge of business processes, application systems and technical implementation was available in the Business organization as well as in the IT department. Processes were not described other than by way of reference to the method description of the development method as recorded in books. Most of IT work was maintenance and minor enhancements to existing application systems. Projects were mostly release based meaning that several small functional modifications and technical improvements were combined in a release. A project manager was appointed and the release was developed, tested and implemented.
There was not much knowledge available on the subject of size estimating. The cost of IT was not well-known because in the past measurements and analysis of performance did not take place.
The IT sub department Test Services was engaged with System Testing, System Integration Testing and Acceptance Testing. They used a popular test management approach well-known in The Netherlands, an approach that worked quite well. Business Control checked the results of testing conducted by Test Services. They did not perform acceptance tests themselves. Business Control heavily depended on Test Services for conducting testing activities for their business lines, which in the past never has been a problem.
The IT development sub department used a traditional Waterfall development method (SDLC) frequently used in The Netherlands in the eighties and nineties. The method was product oriented and considered as obsolete. Requirements were not addressed as such; focus was on design. Recently Business Control had implemented a Business Requirements process. From this process there was no alignment yet with the SDLC. The starting point for the SDLC were Business Requirements and System Requirements as defined by Business Control. Next the SDLC followed a traditional phasing: Functional Design, Technical Design, Build, Testing, Acceptance testing and Implementation.
Working with Business Requirements was pretty new within Business Control. A RE tool was implemented a year before the outsourcing took place. The Business Control organization was also busy to record their processes in a recently acquired BPM tool. The original plan was to expand working with Requirements to the IT department but due to the outsourcing these activities were stopped. The same was for business modelling, Business Control started at the top layers with recording business processes and eventually IT should drill down the business processes to a functional and technical level respectively. This was not started yet.
System Requirements (detailed Business Requirement addressing modifications to application systems) were defined by Functional Supporters of Business Control. These were delivered to the IT department as input for a change project. For modification of application systems in scope of the business change, a set of System Requirements allocated to software was delivered by Business Control. Based on these requirements the IT department created a Functional Design document. This document was input for the subsequent phase which delivered a Technical Design, which served as input for Build. Constructed components in Build were component tested and component integration tested by developers of IT development. All software in the business change was system tested by Test Services. Next the software was system integration tested and eventually acceptance tested by Test Services and accepted by Business Control.
In the past Business Control was set up according to Business Lines (Front-Office, Back-Office). Business Control teams were specialized to support a specific Business Line. Each Business Control team was staffed by Business Analysts and Functional Supporters. A Functional Supporter actually was a SME on one or more applications systems that supported their business stakeholders. A Business Analyst had a broader scope than a Functional Supporter. The BA covered (changes to) Business processes and all information systems (application systems supported with hardware and infrastructure, and manual processing) for a Business area (end-to-end). A BA was primary engaged in new development while a Functional Supporter was focused on major and minor enhancements and on maintenance releases. In practice the two Business Control types were together responsible for the Business layer of information operations. Functional Supporters collaborated closely with the Information Analysts of the IT department to assess alternatives and possibilities and calculate the cost of IT delivery using function point analysis.
Future state – To Be
From the start of the business transformation, the SPI specialist from the External Provider took over. They defined and implemented a new V model, defined new roles and assigned responsibilities and accountabilities to all roles including the interface with Business Control.
Because Test Services was outsourced there were no testing facilities left over for Business Control to conduct acceptance tests and system integration tests. So Business Control heavily depended on the External Provider for conducting testing activities for their business lines. Because all future IT activities were requirements driven it was agreed with Business Control that ownership of Functional Designs should be transferred to the External Provider. The External Provider should use the Functional Designs as a container for requirements used only during transformation. It was planned to abandon the usage of Functional Designs by the end of transformation.
Instead of defining ´real´ Functional Requirements (in standard requirements format) for each business change the outsourced IT department created a delta Functional Design document as a substitute for requirements, describing the old and new situation of all application systems within the scope of a project or release. Functional Supporters of Business Control reviewed and approved these delta Functional Designs. Changes in these ´functional requirements´ had to follow a formal change management process of impact analysis and -recalculating and re planning the cost and timeframe of project delivery with respects of risks introduced by the change.
A blueprint for a new, hybrid SDLC was made by the transformation manager. The picture below shows the conceptual model of the SDLC depicted as a V model, with on the left side the phasing of Requirements & Design, leading to the decomposition of Requirements from Business Needs to Business, System, Functional and Software Requirements. ´Technical Requirements´ are applicable at implementation level, are not depicted because they are actually no real requirements but standards to be used in the design and construction of software and handled as constraints on the development.) On the right side of the picture you can see the various Integration & Test stages (Verification & Validation). Components are incrementally integrated and tested, from the smallest component (piece of software) to the end result, product or system containing dozens to hundreds of software components, the information system itself.
For each box in the picture below processes must be managed and controlled at each level. Each requirements & design product (left side of the V model) must be reviewed or inspected. Also each delivered product (right side of the V model) must be tested prior to promotion to be integrated and tested at a higher level. Testing is always made up of Verification and Validation.
The transformation approach was to eventually offshore Technical Realization. Prerequisite for going offshore was that Business Control should be able to create and maintain, manage and control high quality Business and System Requirements for the External Provider. And requirements should be served as a contract applying a handshake procedure (quality gate) between Client Organization (Business Control) and External Provider.
The new SDLC
The Business department has a Business Need and is owner of the business change. Business Control is the unit within the business organization, which facilitates business change. During System Requirements Analysis Business Requirements are identified by BAs based on Business Requirements Elicitation from Business Line Management, Product Management and Marketing division. The preferred (targeted) Business Solution or Business Vision, is recorded into a Business Design, the to-be description of future business processing (business level) within the business area, object for change. Existing Business Designs, when available, are updated to reflect the new situation.
The Business Requirements and Business Design in regard to the business change are both input to System Architectural Design. System Requirements detail the Business Requirements. Several objects for change are addressed: software, hardware, infrastructure and manual processing. Based on System Requirements Elicitation, System Requirements are identified as such. For a software application system the detailed business requirements allocated to software (as a part of System Requirements), address the requirements for all application systems in scope of that particular business change. For a new application system or for changes to existing application systems effecting its architecture, hardware or infrastructure , System Requirements allocated to software, and/or hardware, and/or infrastructure and/or manual processing apply and an Architectural Design is created (updated) by Business Architects and IT architects in cooperation with BAs.
The System Requirements allocated to software together with the Architectural Design in regard to the business change are input for System Specification. Functional Requirements (Functional and Non-Functional Requirements) are identified by BAs together with Functional Supporters (SME) based on Functional Requirements Elicitation from Business Operations (user departments and user operations). The output of System Specification regarding behaviour of application systems is recorded as Functional Requirements, a set requirements for each functional application system in scope of the business change. The change (delta functionality) is recorded in a Functional Design. Existing Functional Designs are updated to reflect the to-be situation of functional processes (functional level). The system´s capabilities and quality characteristics of application systems are recorded as Non-Functional Requirements. When the application systems in scope are on the same platform, the same non-functional requirements apply for all these systems, so in that case only one set of Non-Functional Requirements is sufficient for this change. Non-Functional Requirements are created per platform. The Back-Office systems require another platform than the Front-Office systems.
The Functional Requirements in regard to the business change together with the Functional Design are input for Technical Realization. Software Requirements are identified by SME (BA) together with Technical Supporters (Application Management) based on Software Requirements Elicitation from IT Operations (supporting departments and IT operations). The output of Technical Realization is recorded as a set of Software Requirements for each technical application subsystem in scope of the business change. Design standards (´Technical Requirements´) are identified by technical designers in cooperation with IT architects. Based on Functional Requirements and Design Standards the change (delta functionality) is recorded in a Technical Design. Existing Technical Designs are updated to reflect the to-be situation of technical processes (implementation level).
The Software Requirements from Technical Realization together with their Technical Designs are input for Build. For Build Programming standards (program languages and (re)usage, platform standards, etc.) serve as ´Technical Requirements´. Software Requirements and Programming standards are input for component design and guide and limit the way Build is done. Delivered building blocks (programs) are component tested and clusters of components are component tested. Software may be off the shelf. Existing programs, modules and components may be used to create the results from Build. The output from Build is tested software.
The changing role of the BA and Business Control
A lot has been written about the role of the BA. The experience in this article goes back to 2007/8 when the author was involved in a complex business transformation program. Life for a BA in those days was less complicated than nowadays. To bridge the gap to 2015 I read Angela Wick´s interesting article ´The BA Role: Has it Really Changed in the Last 15 Years?´ (posted July 2015) In this final paragraph you can see that due to outsourcing and reorganization the role of the BA certainly was affected. It has considerably matured to a higher level!
When you focus on the changes of the BA role you can say that the primary role of the BA did not really change. As discussed previously tools and techniques, processes and procedures to be used by BAs (and Functional Supporters) and also roles and responsibilities of adjacent roles in the process have changed. Also some deliverables have changed due to the implementation of the new SDLC and the change management interface process dealing with product related communication and decision making by both Business Control and the External Provider. A complete new task was required within Business Support: Control of outsourced IT.
Because testing was outsourced a stronger and more formal collaboration between BAs and the test teams of Test Services was needed. BAs also needed to help Functional Supporters to make up and prioritize test cases for system integration testing and for acceptance testing. In the new situation the BA was always responsible for business changes regardless of size, complexity and risks involved, and accountable for his business stakeholders. Related to responsibilities a distinction in new development, minor and major enhancements and maintenance releases was not of interest any more. BAs delegated work to Functional Supporters who were responsible for validating the integration of application systems, hardware and infrastructure and manual processing, so-called system integrated software, but the BA remained accountable toward his business stakeholders.
BAs were forced to strengthen their elicitation and communication skills and techniques to account for questions risen by the cross-functional connections; information analysts, requirements analysts, technical designers and developers of the External Provider. Not to mention project managers and release coordinates who were involved with managing project delivery. Helping the outsourced teams to discover requirements strengthen analysis techniques to make the critical connections between functions, processes, business rules, data and user experience end to end.
BAs had to increase the use of collaboration techniques such as conference calls and video sessions with offshore to define solutions for requirements issues in collaboration from a diverse group of stakeholders who are not within the Client Organization´s environment.
The BA is now more aware of the roles and responsibilities of (external) stakeholders. The External Provider implemented a strict change management process in which Business Control had to pay for changes to agreed work in progress. This caused changes in tolerances for business cases to address the changing needs and requirements of the Client Organization. So the mindset and behaviors of BAs changed as well.
Time and cost have always been focus of project delivery. Due to outsourcing and the goal of both the Client Organization and the External Provider to reduce the cost of delivery, the External Provider applied strong pressure on the project teams to deliver solutions faster and at less costs. End-to-end working more efficiently was needed to comply to this new situation. This pressure resulted in tighter timelines for Business Analysis and Design and for more emphasis on business and development risks. Delivery of acceptance criteria together with the requirements gave more insight of what stakeholders found acceptable and important.
Also BAs needed to reevaluate how to document requirements and watch for a suitable level of detail of the requirements in regard to each audience (concise, not too vague, not going into too many details and prohibit implementation focused requirements). In the past non-functional requirements were hardly addressed which lead to delay in the delivery of requirements.
Lessons learned
A big challenge was to align the process models between Customer Organization and External Provider. Soon it was decided by transformation management to define and standardize a set of dedicated documents addressing the various process interfaces between Customer Organization and External Provider. A most important interface was the Change Management Interface. In this document acquisition, development, managerial and supporting processes (DBA, QA, Configuration Management, test environment management) processes were aligned through products only. The idea was that products, which are the results of a process should be used in the communication between Customer Organization (Business Control) and External Provider (Account Management IT). The actual way of working of a Customer Organization process may deviate from the similar process used by the External Provider.
The BAs were not accustomed to formally record the needs and requirements for Product Management. Based on issues from IT development projects some product characteristics or product modifications were delivered in a very late stage. Business Line Management themselves were also informed late about these changes which sometimes triggered additional changes to business processes and requirements to adjust to the new situation. This caused delays in project delivery. Suggested solution was that the BAs should communicate ALL requirements in regard to ANY business division (single point of contact). The External Provider should never have a direct contact in the Client Organization to sort out information as was done before outsourcing. The BA should always be the linking pin and single-point-of-contact.
The BAs were not accustomed to formally record the needs and requirements for security, IT control and for compliance to (inter)national rules & regulations (Regulatory Requirements). Based on issues from IT projects these requirements were delivered in a very late stage. Business Line Management was hardly aware of these requirements. In the past only IT had the real knowledge how to address aspects of Confidentiality, Integrity and Accountability aspects (CIA) and implement them in their application systems and infrastructure. The outsourced IT did not have sufficient and up to date knowledge on compliance related issues. This caused delays in delivery. Suggested solution was that BC should acquire the necessary knowledge and be responsible for keeping this knowledge up to date. Also BAs should always be aware of (changes in) Regulatory Requirements and communicate these changes to the External Provider as part (subtype) of their Business Requirements.
Existing Business Designs had to be updated to reflect the to-be situation of business processes. Because recording of business processes was in execution not all business processes were documented yet. This meant that the way interfaces to business processes actually worked were not always known in advance, at least not explicitly known in a way that makes creation of requirements possible and complete. Suggested solution was that in case it was clear that not all requirements were ready but start of a development project could not be postponed because of fixed delivery dates required by business or from external sources, a weaver procedure and quality gate procedure was implemented. Exceptions were recorded and accepted in advance including late delivery of some requirements.
In the past the BA together with the Functional Supporters made up the business change and went to IT to discuss feasibility, risks and asked for an estimate of the initial cost of development. When this was all clear the BA complemented the Business Case for the business change and requested agreement from the accountable business manager. If this was settled a project manager was assigned to set up a plan for a development project. In the new situation the Information Analyst was on the payroll of the External Provider, which made communication more formal.
Because in the past Functional Designs were used in IT department as the only way and place for documenting the functionality of application systems, and IT staff was accustomed to this way of working, the new SDLC temporarily embraced the old style of working with Design documents together with the new style of working with Requirements. In the new approach creation of a Functional Design was a means for verification of completeness and correctness of Functional Requirements. Just like the creation of a Technical Design was a means for verification of Software Requirements. This approach actually was the same as used within Business Control. Creation of a Business Design was a means for verification of Business Requirements. And creation of an Architectural Design was a means for verification of System Requirements.
The advantage of this approach was that everyone could easily learn from working with requirements. The first step was the technical level. First candidate for offshore was Technical Realization (set up a technical structure, component design, build, component test and component integration test). When offshore IT should be able to make Software Requirements based on Functional Requirements it should mean that the quality of these Functional Requirements was sufficient. If Software Requirements were a correct basis for making up a Technical Design it proved that the quality of the Software Requirements was sufficient. Next step and subsequent planned level for offshore should be the functional level. When offshore IT should be able to make up Functional Requirements directly based on System Requirements allocated to software set up by BAs and Functional Supporters from Business Control, it should mean that the quality of these requirements was sufficient.
Because in the past there were no requirements available, the basis for acceptance testing by business stakeholders were the Functional Design documents. Because creation and maintenance of Functional Designs was outsourced to the External Provider and gradually should be out phased to be replaced by real requirements, a new norm/standard was needed for business acceptance: Business Requirements together with System Requirements allocated to software. Because Software Requirements address the application systems at low-level this was not of interest of Business Control representing business stakeholders. Outsourced IT has been changed to a black box.
Business Requirements from Business Control and detailed business requirements allocated to software (as a part of System Requirements) delivered by Business Control, were stored and managed in a RE tool. Because the IT department at first was not involved in the usage of requirements, they did not make use of this tool at the time of outsourcing. Instead downloads in Word were made by Business Control and delivered to IT. When a change in Business Requirements or System Requirements was needed, IT ´simply´ received a new download. Because no dedicated RE tool was used in this particular area of the External Provider either, it was decided to proceed to use Word till enough experience should be captured working with requirements and it was believed to be efficient and economical to use a dedicated RE tool.
Business transformation requires much time & energy. You sometime advance three steps and then you fall back two steps. But the process is very relieving and once finished you have made a mark!
ABOUT THE AUTHOR, MARTIN MULLER
Martin has a background in Business Economics and a broad working experience in business transformations. For more than 30 years he worked in The Netherlands for an international software delivery organization as a project manager and trainer in project management, strategic advisor, management coach, process improvement specialist and Quality Assurance manager.
In the quality community Martin is a well-known and recognized person with a strong affinity and drive for quality, processes and people. For the SPI foundation in The Netherlands Martin published on subjects as quality, requirements and command and control of (outsourced) IT. Martin also set up an IREB CPRE Requirements Management correspondence course for IMF, International Management Forum, a Dutch Business/IT correspondence courses training provider.
Martin extensively worked in the area of Business and IT improvement as a transformation manager and requirements expert. He is a highly regarded expert on requirements management and software development methods & techniques and is currently writing an inspiring, practical management book on Requirements Engineering for Business use. This non-technical book addresses RE from outside the IT domain. It provides insight in practices and cuts down organizational and technical complexity in a way organizations can really benefit and obtain success from their own insight in RE.
Martin frequently engages in change programs and CMMI implementations and supports line & project management and clients on process improvement, organizational change, performance and productivity issues, quality measurement and benchmarking.
Martin can be found on LinkedIn http://www.linkedin.com/pub/martin-muller/4/103/821