Originally published November 29, 2007
Editor's note: In the first part of this three-part series, Baseline consultant Linda McHugh examined the problems endemic to effective business-IT alignment. In this article, she discusses how IT can apply realistic and established tactics to address the alignment challenges through planning and project methods.
Acknowledging that culture, as manifested in organizational structure, is the key barrier to alignment is scary and demoralizing because culture is so pervasive and difficult to change. Fortunately, there are a number of indirect ways to chip away at culture without reorganizing. Persistence, consistency and opportunism are the keys to success in chipping away at the problem over the long term. The following tips represent opportunities for both IT and business functions to take the initiative.
It’s easier to tweak an existing process than to introduce a new one. Almost every company has some sort of formal planning process whose activities can be easily modified to enhance alignment and create an environment conducive to ongoing collaboration.
Capacity Planning. Add a step to the planning process whereby IT interviews business users and workgroup managers to uncover business intent that will substantially change the volume of existing transactions. If business users complain about outages or the impact of IT performance on their ability to do their jobs, they are likely to jump at the chance to provide information that promises to ease their pain. If your IT environment is stable or its problems are invisible to most business users, you may have a harder time interesting them in talking to IT; under such circumstances, it may be better to start the process using an electronic survey and then follow-up face-to-face or in small groups to explore unclear or problematic input.
Talk to people who really know about volumes. Vice presidents and directors are experts on the new end state they expect to create. Front line staff, on the other hand, know intimately what takes place daily and in what patterns.
Conduct interviews close enough to the completion of business planning that plans are stable. If you’re too early, you risk forecasting capacity on pipe dreams. If you wait too long, IT will have trouble integrating the input into their plan on time.
Keep the interview to 30 minutes by tightly focusing your questions. If the interviewee wants to talk longer, so be it, just don’t require any more than a half hour. Be sure to take good notes; you’ll need them to aggregate and analyze.
Come armed with facts from the past year – charts and graphs are wonderful ways to communicate facts and depersonalize touchy topics. Show current performance against capacity limits, and use that information to discuss interruptions, failures and outages in terms of business impact and tolerance. Try to uncover the business cause of peaks and valleys; maybe there’s a way to spread them.
Finally, be sure to close the loop with the interviewees once the capacity plan is developed. They need to know they were heard and their input was used. Similarly, if budget for capacity is cut and the cuts are likely to impact a particular activity, establish the situation as a shared issue to be addressed collaboratively.
Service Level Agreement Check-Ups. Although service level agreements (SLAs) should be renegotiated whenever business needs change, they should also be reviewed regularly for continued relevance. Setting up a review is as simple as including the date for review, a review interval or an expiration date when you create or modify the agreement.
At a minimum, include the business signatory on the SLA (most likely the business sponsor), the IT person responsible for the operation and support of the system or application covered by the SLA, and the data steward. There can be advantages to including other stakeholders and treating the session as a type of summit meeting.
Use the format and organization of the SLA to structure the agenda, but also include topics that create an opportunity to raise questions about future plans and emerging technologies. The scope should provide IT advanced warning on emerging business needs and priorities that may affect IT planning, and give business stakeholders an opportunity to consider the advantages and disadvantages of emerging technologies and potential enhancements.
Be sure to document the key issues and decisions, and give participants a chance to validate the minutes. Then update the SLA as agreed, and post it where stakeholders can access it – open communication and transparent interactions are required to build trust, and thus make it possible to resolve misunderstandings based on documentation instead of recollection. We recommend making the session minutes generally available for the same reasons.
Business Process Observation and Mapping. IT is full of technology experts, but they don’t understand the daily reality of your function – not really. Without that awareness, it’s very hard to design a solution that fits daily routine, offers an interface simple and logical to those users, or simplifies procedures in ways that the function values. A comprehensive map of the business activity (who does what when, in what order and for how long) helps IT understand the context in which the solution must fit.
In general, the best person to observe and map is the business analyst. In some organizations, the business analyst reports to the business function. In others, it reports to IT; and in some, it’s a position matrixed between IT and the business. Whatever the reporting relationships, be sure that the business process is accurately and comprehensively captured. It may make sense to team the lead business person (e.g., call center supervisor for a call center application) with the IT architect who will be designing the solution for joint observations.
If IT is stretched too thin or doesn’t have the skills to do the job, then consider having your business analyst tutor IT. A third option is to let IT handle the observation process in their own way but have a validation step where front-line businesspeople sit down with IT to review the process map and answer questions about what was observed before IT goes any further.
What’s the incentive for IT to participate? Why should they go through this extra step? There are a number of benefits for them just in terms of designing and delivering a usable solution. But there’s also a strategic advantage in fully grasping the business activity they’re enabling, particularly if it requires new infrastructure that can be leveraged for other applications.
Standardize Application Descriptions. In most companies, finance develops and manages the planning templates and process. As a result, they reflect a financial perspective – and time frame. Establishing a common template for outlining key aspects of a needed business system or application frees everyone to begin planning for new development as the need emerges, and enables a cross-functional comparison of needs to:
Figure 1: Example of a Description for a “Partner Profile” Application
Resource Allocation. The problem with relying on the formal budgeting cycle for allocating resources to projects is that business needs don’t evolve synchronously with the fiscal year. Furthermore, budgeting only allocates financial resources – the specific skills and knowledge required for the project tend to be concentrated in a few individuals who are often overextended. The alternate option is to allocate individuals who have weaker qualifications. Both circumstances introduce risk.
We recommend separating the identification, description and prioritization of new business applications from budgeting. Here’s how:
At any given time, the priorities for allocating both financial and human resources to projects are known without disrupting the existing planning and budgeting cycle. Furthermore, posting a list of portfolio applications, current status and the sponsor on the company’s intranet can help avoid redundant requests and improve general understanding of current priorities.
Performance Profiling. As part of each SLA negotiated with IT, require a report on the technical performance of the system or application. The information allows both the business and IT to monitor technical performance against requirements relevant to business activity, and assures fact-based problem solving should technical performance degrade – too often such issues are assessed on perception instead of metrics, and generate arguments instead of solutions.
What do we mean by technical performance? Business performance includes the business metrics that tell you how well the targeted function is performing against plan. A marketing organization, for example, might monitor business metrics like the campaign conversion, defection rate and cost per acquisition. Technical performance depends on metrics that reflect how well the systems and applications supporting the business function are performing. Typical technical metrics for a marketing system might include: on-time data loading, trapped entry errors and unplanned outages.
Although application and system development efforts are usually considered the province of IT, in an aligned organization, the sponsoring business function participates in the project and is accountable for key decisions. Here are some ways to build alignment into your development process.
Requirements Definition. Issues about requirements are about as old as those about alignment. Baseline believes the two fundamental problems are:
Both weaknesses are easily overcome by making sure there are four separate components of requirements developed somewhat linearly before any thought is given to the solution: business, data, functional, and technical specifications.1
Business Requirements. Business requirements are best gathered by a business analyst who reports, ideally, into the business function. When the business analyst reports to IT, communication and trust can be issues.
Requirements are best gathered in one-on-one interviews with a representative sample of business users, and enhanced with information from business plans, existing reports and other relevant artifacts. Why one-on-one? Because group sessions tend to yield results skewed on perceived power and assertiveness. Group sessions are best left to the end of the requirements activity, and used to demonstrate that everyone was heard, work through inconsistencies, and validate the requirements. Why a representative sample? Because challenges, awareness and agendas differ with role and responsibilities; a value-adding sustainable solution addresses them all.
The objective of each interview is to understand specific business actions and questions. Asking questions like “What information do you need?” or “What do you want the application to do?” encourages answers like “Columns 6 and 7 from the XYZ database” or “I need Oracle CRM.” Instead, ask questions that focus on the interviewee’s responsibilities and the difficulties he has fulfilling them. Don’t miss the opportunity to estimate solution value by asking how much time is spent each week correcting X, how fixing Y might affect the customer, or what the interviewee could do if task Z were eliminated.
Take notes or record the session. You are sure to miss details or confuse who said what as you complete the interviews. You need to be able to refresh your memory.
As you complete the interviews and analysis, engage the data analyst so that he can begin to derive the data requirements while you finish documenting the business requirements – this little bit of overlap can speed the requirements activity substantially.
Include among the business requirements how the business will evaluate the solution during acceptance. Declaring acceptance criteria and evaluation procedures up front prevents surprises at the end of the project.
Data Requirements. The business analyst passes the results of the interviews with the stakeholders to a data subject matter expert, data steward or data analyst who uses them to identify the information required to meet their needs.
The data analyst creates or enhances the logical data model to identify existing subject areas that need to be tapped as well as new or enriched subject areas that will be required. Physical data models are completely irrelevant at this point; the data requirements are strictly logical and business-based.
Once the data analyst has identified the needed information, he does a quick survey of sources to identify those that might become systems of record; if there’s time, he may also profile the data in each potential source to roughly grasp the their quality problems. Information for which there’s no known source is similarly identified, and the business rules that will govern the creation or conditional use of data are documented.
Finally, the data analyst creates a traceability matrix, which links each business question to a business objective (both from the business analyst’s work) to a data requirement, and subsequently to a functional requirement. Although traceability matrices are tedious to develop and maintain, they provide a quick means for assessing who will be impacted in what way by anticipated changes to a source, a data element or function. Such impact analysis is another critical success factor for business-IT alignment.
Functional Requirements. Typically, the business analyst derives the business functional requirements while the data analyst is working on the data requirements. Like the data requirements, functional requirements are derived from the business requirements. They have to do with the way business users need to work, their interface preferences, accommodations required for skill gaps, and any other constraints on the user interfaces. In most cases, it behooves the business analyst to prototype interfaces as it will be much cheaper and easier to get commitment or corrections from business stakeholders before anything is designed and coded.
Once the business, data and functional requirements are documented, the business analyst validates them with the interviewees and secures sign-off from the sponsor. Adhering to this procedure assures that IT does absolutely no work – design or development – until the business certifies in writing that the requirements are complete and correct, and that any subsequent changes in requirements will be negotiated between the sponsor and IT to manage scope creep and changes to the project budget and schedule.
After the business sponsor signs off on the requirements, the project lead shifts to IT until the user acceptance activity.2 At this point, IT has all the business information needed to define the technical specifications and begin solution design. Similarly data professionals have what they need to begin in-depth data analysis and development activities.
Status Reporting. Communication of project status is important, and it is our view that different audiences need different status information. Most project methodologies only focus on two audiences: those on the project team and the project sponsor.
Baseline knows that communicating status to business users is essential to setting and managing expectations (another aspect of alignment). These individuals care about the status of the project in
terms of what will be delivered when and how it is expected to change their daily activities – for the most part, technical details are of little interest. The project manager may wish to tap
the business analyst to communicate progress, issues and new insights to the business stakeholders since she may be better acquainted with their interests and concerns.
Acceptance. In most cases, there need to be two acceptance activities: data validation and case study acceptance.
The purpose of data validation is to have business stakeholders declare that they trust the data coming from the solution. Depending on the solution, that may require looking at data input from source systems, tracing it through a cleansing process, manually checking business rule calculations, evaluating error trapping, and determining that the output is as expected.
Data validation is done by business stakeholders who already know the data and are respected by their peers for their knowledge. Likely candidates include analysts who manually prepare reports or correct errors. If your company has a data stewardship program, then the relevant data stewards might be entrusted with the job.
Figure 2: Sample Data Validation Instructions for an NCOA Application
Once the data has been certified, evaluators focus on how well the solution fits into routine business activity and supports users as specified in the business requirements. Case studies that emulate real business activities allow business users to step through typical activity using the new solution and evaluating it against the requirements.
Figure 3: Sample Use Case for Evaluating User Acceptance of an NCOA Application
The alignment advantages to designing and executing a rigorous user acceptance include:
The final article in this series will address how organizational infrastructure plays a role in business-IT alignment.
Recent articles by Linda McHugh