Executive Summary

IT departments have long been maligned for their perceived inability to deliver technical solutions that meet business requirements in a cost effective and timely manner. This results in a number of consequences for both the business and IT. Precious funds are spent on technology solutions that fail to deliver the required value. Point solutions proliferate causing a brittle and overly complex technical environment that leads to increased costs and reduced business agility. The ability of IT departments to take on new work is hamstrung by the ever increasing maintenance effort to support existing systems. The reputation of IT as a trusted partner is eroded which can lead to shadow IT departments cropping up across the organization, further exacerbating the problem.

A staggering number of projects fail due to inadequate requirements development and management. These failures can manifest themselves through missed deadlines, cost overruns, poor usability and reduced business value. The project sponsor’s needs and the end users’ needs are often at odds with one another leading to conflicting requirements. The unfortunate result of this requirements disconnect is rework which is astronomically more expensive than delivering the right solution in the first place.

Requirements come in many different flavours. There are business requirements, functional and non-functional requirements all the way down to detailed technical requirements. These requirements can conflict with one another resulting in dissatisfied end users or unhappy technical staff. The management of requirements is a core competency that IT departments must nurture through a combination of people, processes and communication.

All is not lost. There are many strategic initiatives that can be undertaken to address this problem. These include IT governance, enterprise architecture and organizational changes that will place an increased emphasis on aligning IT investments with business priorities. These initiatives span the organization, take significant time and effort and require substantial buy-in to initiate and maintain.

This research note, however, is focused on providing tactical solutions for the CIO. There are numerous activities you can begin now to seize the initiative and begin closing the requirements gap. In particular, this paper focuses on the following tactical initiatives you can undertake to bridge the requirements gap:

· Manage client requirements through a structured process

· Develop a Business Analysis Capability

· Use Enterprise Architecture Modelling Tools

· Place an increased focus on User Experience

Structured Agility

In many organizations end users have multiple channels to request work from the IT department. They may deal with the service desk, business analysts, software developers, multimedia resources and more. When the process is not clearly defined it often results in your users finding the simplest way possible to get what they want. They are unlikely to sit through a series of meetings with a business analyst or create a formal change request when they can call a software developer directly to request a change. It appears to the end user that they are getting exceptional customer service but this behaviour, repeated frequently enough, can cause a ripple effect that degrades the overall performance of the entire IT department.

This lack of control can result in a growing requirements gap. Individuals may request changes that meet their specific needs while not considering the requirements of the other stakeholders involved. Technical resources without requisite business knowledge may make incorrect assumptions that lead to expensive rework once the implications are realized.

There needn’t be a single process for requesting work from the IT department however the processes must be published, understood and audited. Clearly, a request for a new business solution won’t follow the same process as a request for a new laptop computer. The processes must direct requests through the appropriate channels in order to deliver the most business value at the lowest possible cost.

Consider the following situation:

A key stakeholder for a particular business system realizes that software changes are made to comply with a new corporate policy relating to records retention. They do not realize that there is a corporate records management solution that has recently been implemented and whose use is being phased in across business units.

Scenario 1

· The stakeholder, eager to be ahead of the curve, calls up the software developer that typically works on their bespoke document management system and with whom they have a relationship.

· The developer, through a series of discussions, determines the requirements and modifies the solution that meets the needs of this particular individual.

· After the work is completed it is realized that there is a corresponding corporate initiative to implement a records management solution and that the work that was done is non-compliant.

· Expensive and time consuming rework is required in order to bring the solution into compliance.

Scenario 2

· The stakeholder discusses the requirements with the business analyst assigned to his or her business unit.

· The business analyst documents the requirements.

· The business analyst discusses the changed requirement with her supervisor who is aware of the corporate policy change and the new records management solution

· An architecture review is conducted to update the requirements model and assess the impact of change. The architecture review will also identify any pre-existing technical inventory that can be used to reduce the integration effort.

· Armed with this information, the developer builds a solution that is compliant with both the new corporate policy, existing architecture principles and the technical requirements to integrate with the new records management solution.

The second approach balances the many different aspects of requirements through a structured process. The stakeholder’s needs are examined in the context of the overall corporate direction to ensure alignment. They are then examined from an architectural perspective to ensure that architecture requirements are also satisfied. Only after this has taken place will development begin – with a much greater level of certainty about what should be delivered.

The CIO must take an active role in establishing and communicating both the processes and the rationale behind them. There are users that are adept at navigating the current lack of process to their advantage who will be unhappy with these changes. The CIO must come armed with data to demonstrate the ineffectiveness of the current state of affairs and be able to articulate why things need to change.

Through the tenacity of the CIO the organization will soon reap the benefits of these changes. IT will be better able to align projects with corporate direction. The relationship between the business units and IT will improve when it is realized that IT is a proactive partner that can help place requests in a broader organizational context. The reduction in rework will enable IT increase its capacity to deliver technical solutions.

Analyze the Business – with the Business

Business analysis is one of the most important professional disciplines that traditionally fall within the IT domain. The Business Analyst is responsible for bridging the gap between the business and IT departments. Effective business analysts have a deep understanding of their customers’ businesses while simultaneously possessing a strong technical background. This allows them to help their customers work through their requirements, document them and translate them into specifications IT can use to build solutions.

Too frequently there is an insufficient emphasis on the role of the Business Analyst and the optimal client relationship model to maximize the opportunities for success. There can also be inefficient internal organizational processes in place to ensure that Business Analysts work effectively with Project Managers and Software Developers. A lack of clarity can lead to redundancy, conflict and confusion which results in suboptimal outcomes for the business. Project Managers are not Business Analysts. Software Developers are not Business Analysts. Table 1 outlines the stark differences in these roles:

Table 1

A lack of understanding of the Business Analyst role, or perhaps having the wrong people in those roles, can lead to a dysfunctional dynamic within the IT department itself. In the absence of clearly defined and communicated roles software developers often see little value in the role of a Business Analyst. They may see them as unnecessary intermediary between their end-users and themselves. They also see Business Analysts as slowing down their progress and adding unnecessary complexity to the software development process.

The most effective Business Analysts possess an excellent knowledge of their customers’ business. They understand the people and processes along with the legal and regulatory requirements. They can speak the language of their customers. Through this knowledge they are more easily able to gain trust and establish relationships. Their understanding of IT allows them to work closely with both their customers and IT in order to ensure that requirements of both groups are as balanced as possible.

The CIO must take the lead in defining and promoting the role of the Business Analyst. It’s critical that they meet with their business unit customers to discuss the benefits and implications of having a strong business analyst capability. It is also imperative that the CIO meet with their staff within the IT department to have similar conversations. The earlier in the process concerns can be identified the more easily they can be mitigated.

The CIO must work to develop the customer service framework within the Business Analyst will operate. This will include defining whether a business analyst will assigned to a specific customer or whether they will provide service to multiple customers/business units. This can be a functional of business operational realities, resource constraints or both. They must also implement and communicate the processes that the business analyst will support including (but not limited to); requirements gathering, architecture, change requests, IT service requests.

With a clear definition of the role of Business Analyst the CIO will be able to ensure that IT’s customers are provided with a higher level of service. When the business feels as though they have a trusted partner in IT they will be more amenable to working with IT to define more complete requirements resulting in better solutions. A deeper understanding of the customers’ businesses will help bridge the requirements gap by having an ongoing dialog with the both the business units and IT.

Architecture: Moving from Static to Dynamic

The traditional approach to gathering, documenting and managing requirements is plagued with problems. Meetings are held, documents are created and signed off and promptly left on the shelf to collect dust. As the inevitable changes occur over time these documents are not updated which creates a lack of clarity about the functions a given system is intended to perform. This can lead to confusion, misunderstandings about what was agreed to and negative repercussions for IT.

Architecture comes in many flavours and means different things to different people. You must begin to think of architecture as an ongoing process that is not solely focused on technology. An architecture capability should encompass both the business and technology domains. This will allow you to understand technology decisions in the context of business requirements. Changing requirements will then flow through the architecture process to understand the impact and scope of the change.

Enterprise Architecture is the practice of documenting and analyzing an enterprise from the strategy, business and technology perspectives. This is a strategic initiative that falls outside the rubric of IT although there is a significant opportunity to take aspects of Enterprise Architecture in order to close the requirements gap. Taking these steps will also position IT well when and if an Enterprise Architecture program is kicked off.

In order to properly conduct this documentation and analysis a metamodel is populated that shows the relevant entities and their relationships to one another. Modelling tools are used to populate the metamodel and generate analysis and documentation. The power of these tools is that they provide a mechanism to manage requirements and understand the linkages between other system components. You do not need to initiate a full scale Enterprise Architecture program to take advantage of the benefits that these tools offer. Figure 1 shows a simple example of a metamodel.

Figure 1

(Schafrik)

You must change your perspective from the requirements documents being the primary deliverable from the business analysis phase of a project. Instead, you should think of the requirements documents as being the intermediate step with the population of the model as the goal. When the requirements model is complete you can link those requirements to use cases, business processes, data entities, application services et cetera. This will provide you with traceability through the system so you can clearly demonstrate how each requirement is being met.

EA tools also serve the purpose of generating documentation from the model. These tools can generate a variety of viewpoints that serve to provide stakeholders with the view into the system that they need. The benefit of being able to sit with your end users and demonstrate, in real time, how each of the requirements is being met prior to writing a single line of code will realize themselves in reduced cost and rework and shorter development cycles.

Bridging the requirements gap will require you to rethink not just the process but the tools you use to gather and manage requirements. Changing your paradigm from one of documentation to one of modelling will yield significant advantages through increased traceability, having a system of record for requirements and being able to understand the impact of changes to requirements. When documentation is generated from the model it is current and accurate which will support more effective requirements management.

User Experience: Grey Windows are so 1999

Enterprise software solutions have a long history of being unwieldy and difficult to use on top of not being pleasing to the eye. User experience requirements are traditionally not documented in significant detail which leads to the scenario where the end user is not satisfied but IT can proudly hold up the requirements document with a check mark beside each line item. If the perceived quality of the solution is low then users will be more likely to believe their requirements have not been met. Perceived quality is why auto manufacturers spend a significant amount of time and money ensuring doors close with a solid feel and that the dashboard feels pleasing to the touch.

The key point to recognize is that user experience requirements are equally important as the other, more widely understood types of requirements such as business, functional and non-functional. Identifying and delivering on these requirements will result in increased user satisfaction, productivity and adoption.

Hire a User Experience Designer (UED) to work with your end users to truly understand their requirements and translate them into a simple and compelling experience. Allow software developers to focus on the beauty and elegance of dependency injection and implementing service locator patterns.

The UED should also use a lightweight mock-up tool to iteratively build the user interface specification in a visual format that the end users can understand. These software tools provide the ability to very quickly make changes to the user interface so users can immediately visualize the impact of their decisions. These tools are very inexpensive and easy to use and can result in significantly reduced costs. An experienced UED using a mock-up tool and an iterative design approach can build the user experience specification vastly more quickly and at a much lower cost than a software developer using traditional methods. Figure 2 shows a sample mock-up created by this type of tool.

Figure 2

This approach can help in ways that you may not have considered. It will force your software developers to build higher quality, more loosely coupled software. While the UED develops the user experience your software developers can build the underlying value added business logic. In order to efficiently integrate the two work products software must be developed with this in mind which necessitates the use of design patterns and a loosely-coupled design. This will result in systems that are focused on convention over configuration and can much more easily adapt to change. It will also result in systems that are more compliant with technical requirements thus helping bridge the requirements gap.

Focusing both on modelling and mock-up tools allows you to work on the important concepts independent of the implementation. It allows you to identify problems and work iteratively with your users prior to any code being written. It is much more cost effective to tweak a model or mock-up than it is to rework software code. Doing the leg work up front will can save you considerable time and money down the road.

By placing the right resources and processes in the CIO has a significant influence over the capturing of user experience requirements in an agile and cost effective way. Instead of overlooking the user experience requirements they will be an integral part of the process. Using a rapid, iterative approach the users will be able to more effectively articulate their requirements and see the results of their decisions. Hiring a UED will help those requirements be realized in a manner that creates a better quality user experience.

Dos and Don’ts

References

Brandenburg, L. (n.d.). I’m a software developer, why is this business analyst on my project? Retrieved from Bridging the Gap: http://www.bridging-the-gap.com/im-a-software-developer-why-is-this-business-analyst-on-my-project/

Business Analyst. (n.d.). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Business_analyst

Malik, N. (n.d.). Understanding the root causes of poor software requirements. Retrieved from Inside Archtecture: http://blogs.msdn.com/b/nickmalik/archive/2009/02/18/understanding-the-root-causes-of-poor-software-requirements.aspx

Model Driven Architecture. (n.d.). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Model-driven_architecture

Schafrik, F. (n.d.). A practical guide to developing enterprise architecture. Retrieved from IBM Developer Works: http://www.ibm.com/developerworks/rational/library/enterprise-architecture-maximum-value/index.html?cmp=dw&cpb=dw&ct=dwcon&cr=devx&ccy=zz