Requirements Analysis for Portfolio of IT Decisions in A/E Firms

Outline:

Abstract
Introduction
Research and Methodology
What is the Problem in the A/E Industry?
Requirements Framework & Cognitive Fit
Making Portfolio Decisions
Conclusion
Some Definitions
References

Abstract:

Through a survey of current literature and personal experience within the Architecture-Engineering (A/E) industry, we will explore requirements analysis for Portfolio of IT decisions in A/E firms. Since A/E relies on processes of taking in data and creating information, we are able to easily take a process-oriented approach for this study. Therefore we will take a look at current studies in process-oriented systems outside the industry, and some Data Flow Diagrams (DFD) for typical A/E processes to define the typical requirements in these situations. We will also see that the process-oriented systems need to integrate divergent data, and that this also effects the A/E system requirements. Finally, we will investigate how these requirements can be used in Portfolio of IT decision-making. Through the paper we develop a broad outline that can be used by A/E firms in requirements analysis for Portfolio of IT decisions.

Introduction:

Architecture-Engineering (A/E) Firms today meet many challenges in making decisions on software products that should be included in their Portfolio of IT. Although the Portfolio of IT can include all aspects of technology investment (servers, infrastructure, computers, software, databases, and so on), for this paper we will only be discussing user applications (software). Although the information in the paper can be applied to the Portfolio in general, I am dealing with software issues in specific for the arguments made here.

Within the A/E industry, there is a great diversity in what the requirements should be for software purchases. Many firms, and even many groups within a firm, use differing criteria to make decisions on what products should be within their Portfolio. These groups use requirements to make the decisions that may have no real correlation with the work processes they are going through.[1] In the literature reviewed and in my experiences at A/E firms when requirements are not analyzed and documented it leads to some or all of the following problems:

Different groups within a firm have different software solutions for the same business process
Firms have purchased software that is not used because it does not fit into their business processes
The firm can not evaluate the successes and failures of the software implementation
A software package is picked on the basis of “work-of-mouth”, bells and whistles, or emotional reasoning, rather than on actual value to the business

As can be quickly deducted, the above problems lead to a failed implementation because a proper requirements analysis wasn’t completed. Why do A/E firms not go through a requirements process before selecting software – are they all just being sloppy? The problem is in the complexities of the data an A/E firm deals with in doing their work. Since there is so many types of data coming from so many sources (clients, consultants, contractors, government agencies, vendors, and public relation groups) when putting a building together it becomes difficult to get a handle on the entire set of processes.

These different processes have to be broken down into categories for the project team to accomplish the design, documentations, and construction of the building. These processes cause the software solutions to be selected individually by separate groups only concentrating on their set of processes. It is difficult for the firm as a whole to develop a set of requirements that will deal with the entire set of processes required.

In this paper we are going to tackle defining requirements that encompass all the processes in an A/E firm. This means that we will have to be general in requirements analysis and definition to encompass many idiosyncratic situations. It is the intension of this paper to develop a framework for A/E firms to use in requirements analysis to make Portfolio of IT decision when selecting software.

Research and Methodology:

The data for this paper is compiled from a survey of current literature and from personal experiences at A/E firms over the past 10 years. When researching the issue of IT in the A/E industry there is not a lot of information on the subjects of requirements analysis and Portfolio management. Interestingly, most of the literature is centered on how certain software packages are useful for certain types of processes in a firm. I believe this is a reflection of the problem this paper is trying to initially address. The use of information technology in the A/E industry has not become a standard for the everyday practitioner until the early 1990’s.[2] Therefore the industry only has a decade of practicing experience integrating information technology into the business processes of A/E.

Therefore I also bring some points up in the paper from my personal experience over the past decade working in A/E firms. Over this time period I have been involved in moving firms to using digital Information Systems to replace existing manual systems, as well as manage existing digital systems in place. The information I bring to the paper from these experiences is anecdotal, but I believe valid for defining the scope for further research in this area.

Returning to the surveyed literature, the articles referenced in this paper fall into two categories; A/E literature focusing on their industry, and Information Systems literature focused on Portfolio of IT or process-oriented systems and approaches. As mentioned above, I found no empirical, scientific studies of A/E information pertaining to Information Systems. This led to a void in trying to use past information and analysis to develop a framework to use in the A/E industry.

To meet the gap in the literature, I will assume that the A/E industry is a process-oriented system and use literature from other industries to make assumptions in this paper. Making this comparison to other industries is based on the assumption that A/E firms are process driven, and the literature supports this assumption.[3] This leads to the following assumptions for the purposes of this paper:

Techniques in other process-oriented situations will have to be used for analyzing A/E firms, and seem valid for the industry
Requirement analysis techniques for other process-oriented systems can be carried over to A/E systems
Portfolio of IT decision making for other process-oriented enterprises can be compared to A/E Portfolio decision making

To develop the requirements analysis for making Portfolio decisions on software for the A/E industry we shall look at the processes in the industry within the context of the research done in other process-oriented industries.

What is the Problem in the A/E Industry? :

The industry is suffering from a problem of how to integrate Information Technology into the design and construction processes developed over the last 4000 years, starting with the great architects of Egypt. Since the industry has integrated computers into everyday activity over the past decade, now it is dealing with how that technology is going to work together to better deliver services, like fast tracking projects.[4] This situation has also changed the climate for professionals entering the industry, who now have to attain skills in computers to get employment and promotions within a firm.[5] Architects and Engineers have gone to being the Gods of Egypt to computer terminal users of the 21^st century.

To meet these issues head on, A/E firms have developed different strategies to use technology in their firm. Some firms are trying to use their Portfolio to give them advantage by becoming a “digital master builder”, eliminated manual steps their competition is wasting time with.[6] Other firms are just trying to stay afloat with making sure everyone is working with the same standards, like how they produce their CAD drawings.[7] For all these firms, the worst thing that technology has meant for them is concern for software licensing[8] and keeping up with upgrades[9]

We see from the literature that firms that have a grasp of their requirements and goals in their Portfolio are using IT in two ways; to better analyze the data for design decision and using digital information to eliminate manual steps in the process of building a project. A/E firm Frank Gehry and Associates has been the leader in these efforts, as his firm uses software to create fanciful designs and also pass the digital information on the engineers and contractors to execute the construction.[10] Gehry’s Portfolio has created some of the most complex construction projects ever executed, and within 2% of the budget – uncalled for in simple projects.[11] This is achieved by having a complete digital design path from architect to engineer to fabricator. The Guggenheim Museum in Bilbao, Spain, was done in this way so that the steel was fabricated right from the digital design drawings with no manual transition of information.[12]

Therefore the benefits of developing a solid Portfolio through requirements analysis can help an A/E firm and it’s clients. Engineers that work with Gehry’s firm, like Steve Huey who worked on the Experimental Music Project, say things like this:

When the requirements are to integrate the entire process digitally, the payback can be huge. Unfortunately, in the past A/E firms have used software solutions to tackle the parts of the design process one piece at a time. We hope to take a holistic approach in defining the requirements for an entire A/E firm.

Requirements Framework & Cognitive Fit:

In looking at the requirements for A/E firms, there is a need to look beyond the individual software packages. Information Systems for the A/E industry has typically meant AutoCAD and 3D packages in the past – which have not met all the needs of the design process.[14] Like we saw above with Gehry’s practice, the real power in a Portfolio of IT is in the way it can bring together all the data and processes during the design of a building and actually save time and money, while making clients more satisfied with the final product. What this means from the requirements side is a movement away from which software is “the One” to what Portfolio of software will create the collaboration needed for the processes needed to complete the complicated projects designed by today’s multidisciplinary teams.[15]

To really understand how Information Systems can have a positive effect, we need to look at the value of all the processes used in A/E firms. As with many types of organizations, there is a need to break down processes so they can be assigned to different groups. In the A/E industry these groups would be something like this: Architects, Engineers (Mechanical, Electrical, Plumbing - MEP), Marketing, Accounting, Planners, Project Managers, and Administrators. These groups are getting divergent data in different formats from many external groups, which can be seen in the Conceptual Data Flow Diagram (DFD) below.

If we go down one level from the diagram above we can see the interaction of the different group’s processes (see Level 0 Data Flow Diagram below). In completed their work, all the groups are relying on the other groups for data and information. This is why taking a holistic approach to the requirements needed for all processes would benefit in choosing software for the Portfolio. Unless all the data and information can be shared across processes, time will be wasted and errors increased in manually moving data and redoing work.

The performance of these processes depends on the flow of data and information between these processes. Therefore we need to have a Portfolio were the process-oriented system (the software tools) have a cognitive fit with the process-oriented work (the task at hand in the process) to achieve superior performance. This was found to be true in a study looking at numerous organizations and evaluating their performance correlated to cognitive fit.[16] Since A/E firms rely so heavily on the collaboration of internal and team processes, this cognitive fit needs to stretch across the entire construction project design process to achieve superior performance. We have seen this in the Frank Gehry examples above where his firm achieves great performance because of the cognitive fit between the tools and tasks between all actors in the design process.

Making Portfolio Decisions:

Going through the requirements analysis will define the needs of an A/E firm, but the next step is to take that information and use it making decisions on the Portfolio. If you are working with an A/E firm, the above diagrams can be used as a starting point in defining your requirements. It is very important that the process-oriented approach is used and cognitive fit be revaluated as technology and processes change. The next step is to make decisions based on the business value of the software in relation to your requirements.

When evaluating the Portfolio, we need to take into consideration what value the software will bring to the specific process, and the links between all the processes. As in the requirements stage, we are taking a process-oriented approach in evaluating the value chain of all the processes within the firm. Studies have argued that:

“This process-centric perspective argues that (the Portfolio of) IT creates value for the organization by improving individual business processes, or interprocess linkages, or both. Consequently, the greater the impact of (the Portfolio of) IT on individual business processes and on interprocess linkages, the greater will be the contribution of IT to firm performance.”[17]

The study quoted above found very interesting results when studying corporations from analyzing the operational effectiveness of their Portfolio against their strategic positioning. When the organization was able to strategically position their Portfolio to have both an Operations and Market focus, they had much more operational effectiveness. So, when looking at the different processes in our A/E DFD above, processes can be divided into either the Operation Group (processes producing information for internal entities) or the Market Group (processes producing information for external entities). When making Portfolio decision, we need to ensure that our strategy combines the efforts of both groups of processes so that our focus remains internal and external.

Conclusion:

As the construction process becomes more complicated, the schedules shorter, and the teams more diverse, the use of Information Systems will become more critical for the A/E industry. Technology is taking a larger role in A/E firms, even to the extent that professionals don’t do out to evaluate existing building conditions in person, they can be done with sensors on planes.[18] There are also changes in the software available to complete tasks, and the digital formats that are created to better communicate ideas to clients.[19] Therefore the importance of understanding system requirements and having a strategy for Portfolio of IT decisions when selecting software is important. It is the intention of this paper to be a framework for A/E firms to use to develop such strategies and requirements that could fit within their implementation process, like the IT Interaction Model.[20] By taking a holistic approach to requirements analysis to achieve cognitive fit, and make decisions on the Portfolio base on the value of IT to that fit can improve A/E systems performance.

Some Definitions:

To clarify some of the terms used in this paper for those readers who have questions on how I am using them:

Application software: Computer software designed to support organizational functions or processes.
Data: Raw facts about people, objects, and events in an organization.
Information: Data that has been processes and presented in a form suitable for human interpretation, often with the purpose of revealing trends or patterns.
Process-oriented approach: An overall strategy to information systems development that focuses on how and when data are moved through and changed by an information system.
Key business processes: The structured, measured set of activities designed to produce a specific output for a particular customer or market.
Disruptive technologies: Technologies that enable the breaking of long-held business rules that inhibit organizations from making radical business changes.
Design strategy: A high-level statement about the approach to developing an information system. It includes statements on the system’s functionality, hardware and system software platform, and method for acquisition.

Requirement Analysis for Portfolio of IT Decisions in A/E Firms