what are the core problem solving steps for developing new information systems

• school Campus Bookshelves
• menu_book Bookshelves
• perm_media Learning Objects
• login Login
• how_to_reg Request Instructor Account
• hub Instructor Commons
• Download Page (PDF)
• Download Full Book (PDF)
• Periodic Table
• Physics Constants
• Scientific Calculator
• Reference & Cite
• Tools expand_more
• Readability

selected template will load here

This action is not available.

10.1: Information Systems Development

• Last updated
• Save as PDF
• Page ID 84206

• David T. Bourgeois
• Biola University via Saylor Foundation

Learning Objectives

Upon successful completion of this chapter, you will be able to:

• explain the overall process of developing a new software application;
• explain the differences between software development methodologies;
• understand the different types of programming languages used to develop software;
• understand some of the issues surrounding the development of websites and mobile applications; and
• identify the four primary implementation policies.

Introduction

When someone has an idea for a new function to be performed by a computer, how does that idea become reality? If a company wants to implement a new business process and needs new hardware or software to support it, how do they go about making it happen? In this chapter, we will discuss the different methods of taking those ideas and bringing them to reality, a process known as information systems development.

Programming

As we learned in chapter 2, software is created via programming. Programming is the process of creating a set of logical instructions for a digital device to follow using a programming language. The process of programming is sometimes called “coding” because the syntax of a programming language is not in a form that everyone can understand – it is in “code.”  

The process of developing good software is usually not as simple as sitting down and writing some code. True, sometimes a programmer can quickly write a short program to solve a need. But most of the time, the creation of software is a resource-intensive process that involves several different groups of people in an organization. In the following sections, we are going to review several different methodologies for software development.

Part II: Information Systems for Strategic Advantage

Chapter 10: Information Systems Development

Learning Objectives

Upon successful completion of this chapter, you will be able to:

• Explain the overall process of developing new software;
• Explain the differences between software development methodologies;
• Understand the different types of programming languages used to develop software;
• Understand some of the issues surrounding the development of websites and mobile applications; and
• Identify the four primary implementation policies.

Introduction

When someone has an idea for a new function to be performed by a computer, how does that idea become reality? If a company wants to implement a new business process and needs new hardware or software to support it, how do they go about making it happen? This chapter covers the different methods of taking those ideas and bringing them to reality, a process known as information systems development.

Programming

Software is created via programming, as discussed in Chapter 2. Programming is the process of creating a set of logical instructions for a digital device to follow using a programming language. The process of programming is sometimes called “coding” because the developer takes the design and encodes it into a programming language which then runs on the computer.

The process of developing good software is usually not as simple as sitting down and writing some code. Sometimes a programmer can quickly write a short program to solve a need, but in most instances the creation of software is a resource-intensive process that involves several different groups of people in an organization. In order to do this effectively, the groups agree to follow a specific software development methodology. The following sections review several different methodologies for software development, as summarized in the table below and more fully described in the following sections.

Systems Development Life Cycle

The Systems Development Life Cycle (SDLC) was first developed in the 1960s to manage the large software projects associated with corporate systems running on mainframes. This approach to software development is very structured and risk averse, designed to manage large projects that include multiple programmers and systems that have a large impact on the organization. It requires a clear, upfront understanding of what the software is supposed to do and is not amenable to design changes. This approach is roughly similar to an assembly line process, where it is clear to all stakeholders what the end product should do and that major changes are difficult and costly to implement.

Various definitions of the SDLC methodology exist, but most contain the following phases.

• Preliminary Analysis. A request for a replacement or new system is first reviewed. The review includes questions such as: What is the problem-to-be-solved? Is creating a solution possible? What alternatives exist? What is currently being done about it? Is this project a good fit for our organization? After addressing these question, a feasibility study is launched. The feasibility study includes an analysis of the technical feasibility, the economic feasibility or affordability, and the legal feasibility. This step is important in determining if the project should be initiated and may be done by someone with a title of Requirements Analyst or Business Analyst
• System Analysis. In this phase one or more system analysts work with different stakeholder groups to determine the specific requirements for the new system. No programming is done in this step. Instead, procedures are documented, key players/users are interviewed, and data requirements are developed in order to get an overall impression of exactly what the system is supposed to do. The result of this phase is a system requirements document and may be done by someone with a title of Systems Analyst
• System Design. In this phase, a designer takes the system requirements document created in the previous phase and develops the specific technical details required for the system. It is in this phase that the business requirements are translated into specific technical requirements. The design for the user interface, database, data inputs and outputs, and reporting are developed here. The result of this phase is a system design document. This document will have everything a programmer needs to actually create the system and may be done by someone with a title of Systems Analyst, Developer, or Systems Architect, based on the scale of the project.
• Programming. The code finally gets written in the programming phase. Using the system design document as a guide, programmers develop the software. The result of this phase is an initial working program that meets the requirements specified in the system analysis phase and the design developed in the system design phase. These tasks are done by persons with titles such as Developer, Software Engineer, Programmer, or Coder.
• Testing. In the testing phase the software program developed in the programming phase is put through a series of structured tests. The first is a unit test, which evaluates individual parts of the code for errors or bugs. This is followed by a system test in which the different components of the system are tested to ensure that they work together properly. Finally, the user acceptance test allows those that will be using the software to test the system to ensure that it meets their standards. Any bugs, errors, or problems found during testing are resolved and then the software is tested again. These tasks are done by persons with titles such as Tester, Testing Analyst, or Quality Assurance.
• Implementation. Once the new system is developed and tested, it has to be implemented in the organization. This phase includes training the users, providing documentation, and data conversion from the previous system to the new system. Implementation can take many forms, depending on the type of system, the number and type of users, and how urgent it is that the system become operational. These different forms of implementation are covered later in the chapter.
• Maintenance. This final phase takes place once the implementation phase is complete. In the maintenance phase the system has a structured support process in place. Reported bugs are fixed and requests for new features are evaluated and implemented. Also, system updates and backups of the software are made for each new version of the program. Since maintenance is normally an Operating Expense (OPEX) while much of development is a Capital Expense (CAPEX), funds normally come out of different budgets or cost centers.

The SDLC methodology is sometimes referred to as the waterfall methodology to represent how each step is a separate part of the process. Only when one step is completed can another step begin. After each step an organization must decide when to move to the next step. This methodology has been criticized for being quite rigid, allowing movement in only one direction, namely, forward in the cycle. For example, changes to the requirements are not allowed once the process has begun. No software is available until after the programming phase.

Again, SDLC was developed for large, structured projects. Projects using SDLC can sometimes take months or years to complete. Because of its inflexibility and the availability of new programming techniques and tools, many other software development methodologies have been developed. Many of these retain some of the underlying concepts of SDLC, but are not as rigid.

Rapid Application Development

Rapid Application Development (RAD) focuses on quickly building a working model of the software, getting feedback from users, and then using that feedback to update the working model. After several iterations of development, a final version is developed and implemented.

The RAD methodology consists of four phases.

• Requirements Planning. This phase is similar to the preliminary analysis, system analysis, and design phases of the SDLC. In this phase the overall requirements for the system are defined, a team is identified, and feasibility is determined.
• User Design. In the user design phase representatives of the users work with the system analysts, designers, and programmers to interactively create the design of the system. Sometimes a Joint Application Development (JAD) session is used to facilitate working with all of these various stakeholders. A JAD session brings all of the stakeholders for a structured discussion about the design of the system. Application developers also participate and observe, trying to understand the essence of the requirements.
• Construction. In the construction phase the application developers, working with the users, build the next version of the system through an interactive process. Changes can be made as developers work on the program. This step is executed in parallel with the User Design step in an iterative fashion, making modifications until an acceptable version of the product is developed.
• Cutover. Cutover involves switching from the old system to the new software. Timing of the cutover phase is crucial and is usually done when there is low activity. For example, IT systems in higher education undergo many changes and upgrades during the summer or between fall semester and spring semester. Approaches to the migration from the old to the new system vary between organizations. Some prefer to simply start the new software and terminate use of the old software. Others choose to use an incremental cutover, bringing one part online at a time. A cutover to a new accounting system may be done one module at a time such as general ledger first, then payroll, followed by accounts receivable, etc. until all modules have been implemented. A third approach is to run both the old and new systems in parallel, comparing results daily to confirm the new system is accurate and dependable. A more thorough discussion of implementation strategies appears near the end of this chapter.

As you can see, the RAD methodology is much more compressed than SDLC. Many of the SDLC steps are combined and the focus is on user participation and iteration. This methodology is much better suited for smaller projects than SDLC and has the added advantage of giving users the ability to provide feedback throughout the process. SDLC requires more documentation and attention to detail and is well suited to large, resource-intensive projects. RAD makes more sense for smaller projects that are less resource intensive and need to be developed quickly.

Agile Methodologies

Agile methodologies are a group of methodologies that utilize incremental changes with a focus on quality and attention to detail. Each increment is released in a specified period of time (called a time box), creating a regular release schedule with very specific objectives. While considered a separate methodology from RAD, the two methodologies share some of the same principles such as iterative development, user interaction, and flexibility to change. The agile methodologies are based on the “ Agile Manifesto ,” first released in 2001.

Agile and Iterative Development

The diagram above emphasizes iterations in the center of agile development. You should notice how the building blocks of the developing system move from left to right, a block at a time, not the entire project. Blocks that are not acceptable are returned through feedback and the developers make the needed modifications. Finally, notice the Daily Review at the top of the diagram. Agile Development means constant evaluation by both developers and customers (notice the term “Collaboration”) of each day’s work.

The characteristics of agile methodology include:

• Small cross-functional teams that include development team members and users;
• Daily status meetings to discuss the current state of the project;
• Short time-frame increments (from days to one or two weeks) for each change to be completed; and
• Working project at the end of each iteration which demonstrates progress to the stakeholders.

The goal of agile methodologies is to provide the flexibility of an iterative approach while ensuring a quality product.

Lean Methodology

One last methodology to discuss is a relatively new concept taken from the business bestseller The Lean Startup by Eric Reis. Lean focuses on taking an initial idea and developing a Minimum Viable Product (MVP). The MVP is a working software application with just enough functionality to demonstrate the idea behind the project. Once the MVP is developed, the development team gives it to potential users for review. Feedback on the MVP is generated in two forms. First, direct observation and discussion with the users and second, usage statistics gathered from the software itself. Using these two forms of feedback, the team determines whether they should continue in the same direction or rethink the core idea behind the project, change the functions, and create a new MVP. This change in strategy is called a pivot. Several iterations of the MVP are developed, with new functions added each time based on the feedback, until a final product is completed.

The biggest difference between the iterative and non-iterative methodologies is that the full set of requirements for the system are not known when the project is launched. As each iteration of the project is released, the statistics and feedback gathered are used to determine the requirements. The lean methodology works best in an entrepreneurial environment where a company is interested in determining if their idea for a program is worth developing.

Sidebar: The Quality Triangle

When developing software or any sort of product or service, there exists a tension between the developers and the different stakeholder groups such as management, users, and investors. This tension relates to how quickly the software can be developed (time), how much money will be spent (cost), and how well it will be built (quality). The quality triangle is a simple concept. It states that for any product or service being developed, you can only address two of the following: time, cost, and quality.

So why can only two of the three factors in the triangle be considered? Because each of these three components are in competition with each other! If you are willing and able to spend a lot of money, then a project can be completed quickly with high quality results because you can provide more resources towards its development. If a project’s completion date is not a priority, then it can be completed at a lower cost with higher quality results using a smaller team with fewer resources. Of course, these are just generalizations, and different projects may not fit this model perfectly. But overall, this model is designed to help you understand the trade-offs that must be made when you are developing new products and services.

There are other, fundamental reasons why low-cost, high-quality projects done quickly are so difficult to achieve.

• The human mind is analog and the machines the software run on are digital. These are completely different natures that depend upon context and nuance versus being a 1 or a 0. Things that seem obvious to the human mind are not so obvious when forced into a 1 or 0 binary choice.
• Human beings leave their imprints on the applications or systems they design. This is best summed up by Conway’s Law (1968) – “Organizations that design information systems are constrained to do so in a way that mirrors their internal communication processes.” Organizations with poor communication processes will find it very difficult to communicate requirements and priorities, especially for projects at the enterprise level (i.e., that affect the whole organization.

Programming Languages

As noted earlier, developers create programs using one of several programming languages. A programming language is an artificial language that provides a way for a developer to create programming code to communicate logic in a format that can be executed by the computer hardware. Over the past few decades, many different types of programming languages have evolved to meet a variety of needs. One way to characterize programming languages is by their “generation.”

Generations of Programming Languages

Early languages were specific to the type of hardware that had to be programmed. Each type of computer hardware had a different low level programming language. In those early languages very specific instructions had to be entered line by line – a tedious process.

First generation languages were called machine code because programming was done in the format the machine/computer could read. So programming was done by directly setting actual ones and zeroes (the bits) in the program using binary code. Here is an example program that adds 1234 and 4321 using machine language:

Assembly language is the second generation language and uses English-like phrases rather than machine-code instructions, making it easier to program. An assembly language program must be run through an assembler, which converts it into machine code. Here is a sample program that adds 1234 and 4321 using assembly language.

Third-generation languages are not specific to the type of hardware on which they run and are similar to spoken languages. Most third generation languages must be compiled. The developer writes the program in a form known generically as source code , then the compiler converts the source code into machine code, producing an executable file. Well-known third generation languages include BASIC, C, Python, and Java. Here is an example using BASIC:

Fourth generation languages are a class of programming tools that enable fast application development using intuitive interfaces and environments. Many times a fourth generation language has a very specific purpose, such as database interaction or report-writing. These tools can be used by those with very little formal training in programming and allow for the quick development of applications and/or functionality. Examples of fourth-generation languages include: Clipper, FOCUS, SQL, and SPSS.

Why would anyone want to program in a lower level language when they require so much more work? The answer is similar to why some prefer to drive manual transmission vehicles instead of automatic transmission, namely, control and efficiency. Lower level languages, such as assembly language, are much more efficient and execute much more quickly. The developer has finer control over the hardware as well. Sometimes a combination of higher and lower level languages is mixed together to get the best of both worlds. The programmer can create the overall structure and interface using a higher level language but use lower level languages for the parts of the program that are used many times, require more precision, or need greater speed.

Compiled vs. Interpreted

Besides identifying a programming language based on its generation, we can also classify it through the distinction of  whether it is compiled or interpreted. A computer language is written in a human-readable form. In a compiled language the program code is translated into a machine-readable form called an executable that can be run on the hardware. Some well-known compiled languages include C, C++, and COBOL.

Interpreted languages require a runtime program to be installed in order to execute. Each time the user wants to run the software the runtime program must interpret the program code line by line, then run it. Interpreted languages are generally easier to work with but also are slower and require more system resources. Examples of popular interpreted languages include BASIC, PHP, PERL, and Python. The web languages of HTML and  JavaScript are also considered interpreted because they require a browser in order to run.

The Java programming language is an interesting exception to this classification, as it is actually a hybrid of the two. A program written in Java is partially compiled to create a program that can be understood by the Java Virtual Machine (JVM). Each type of operating system has its own JVM which must be installed before any program can be executed. The JVM approach allows a single Java program to run on many different types of operating systems.

Procedural vs. Object-Oriented

A procedural programming language is designed to allow a programmer to define a specific starting point for the program and then execute sequentially. All early programming languages worked this way. As user interfaces became more interactive and graphical, it made sense for programming languages to evolve to allow the user to have greater control over the flow of the program. An object-oriented programming language is designed so that the programmer defines “objects” that can take certain actions based on input from the user. In other words, a procedural program focuses on the sequence of activities to be performed while an object oriented program focuses on the different items being manipulated.

Consider a human resources system where an “EMPLOYEE” object would be needed. If the program needed to retrieve or set data regarding an employee, it would first create an employee object in the program and then set or retrieve the values needed. Every object has properties, which are descriptive fields associated with the object. Also known as a Schema, it is the logical view of the object (i.e., each row of properties represents a column in the actual table, which is known as the physical view). The employee object has the properties “EMPLOYEEID”, “FIRSTNAME”, “LASTNAME”, “BIRTHDATE” and “HIREDATE”. An object also has methods which can take actions related to the object. There are two methods in the example. The first is “ADDEMPLOYEE()”, which will create another employee record. The second is “EDITEMPLOYEE()” which will modify an employee’s data.

Programming Tools

To write a program, you need little more than a text editor and a good idea. However, to be productive you must be able to check the syntax of the code, and, in some cases, compile the code. To be more efficient at programming, additional tools, such as an Integrated Development Environment (IDE) or computer-aided software-engineering (CASE) tools can be used.

Integrated Development Environment

For most programming languages an Integrated Development Environment (IDE) can be used to develop the program. An IDE provides a variety of tools for the programmer, and usually includes:

• Editor. An editor is used for writing the program. Commands are automatically color coded by the IDE to identify command types. For example, a programming comment might appear in green and a programming statement might appear in black.
• Help system. A help system gives detailed documentation regarding the programming language.
• Compiler/Interpreter. The compiler/interpreter converts the programmer’s source code into machine language so it can be executed/run on the computer.
• Debugging tool. Debugging assists the developer in locating errors and finding solutions.
• Check-in/check-out mechanism. This tool allows teams of programmers to work simultaneously on a program without overwriting another programmer’s code.

Examples of IDEs include Microsoft’s Visual Studio and Oracle’s Eclipse . Visual Studio is the IDE for all of Microsoft’s programming languages, including Visual Basic, Visual C++, and Visual C#. Eclipse can be used for Java, C, C++, Perl, Python, R, and many other languages.

While an IDE provides several tools to assist the programmer in writing the program, the code still must be written. Computer-Aided Software Engineering (CASE) tools allow a designer to develop software with little or no programming. Instead, the CASE tool writes the code for the designer. CASE tools come in many varieties. Their goal is to generate quality code based on input created by the designer.

Sidebar: Building a Website

In the early days of the World Wide Web, the creation of a website required knowing how to use HyperText Markup Language (HTML). Today most websites are built with a variety of tools, but the final product that is transmitted to a browser is still HTML. At its simplest HTML is a text language that allows you to define the different components of a web page. These definitions are handled through the use of HTML tags with text between the tags or brackets. For example, an HTML tag can tell the browser to show a word in italics, to link to another web page, or to insert an image. The HTML code below selects two different types of headings (h1 and h2) with text below each heading. Some of the text has been italicized. The output as it would appear in a browser is shown after the HTML code.

While HTML is used to define the components of a web page, Cascading Style Sheets (CSS) are used to define the styles of the components on a page. The use of CSS allows the style of a website to be set and stay consistent throughout. For example, a designer who wanted all first-level headings (h1) to be blue and centered could set the “h1″ style to match. The following example shows how this might look.

HTML code with CSS added

The combination of HTML and CSS can be used to create a wide variety of formats and designs and has been widely adopted by the web design community. The standards for HTML are set by a governing body called the World Wide Web Consortium . The current version of HTML 5 includes new standards for video, audio, and drawing.

When developers create a website, they do not write it out manually in a text editor. Instead, they use web design tools that generate the HTML and CSS for them. Tools such as Adobe Dreamweaver allow the designer to create a web page that includes images and interactive elements without writing a single line of code. However, professional web designers still need to learn HTML and CSS in order to have full control over the web pages they are developing.

Sidebar: Building a Mobile App

In many ways building an application for a mobile device is exactly the same as building an application for a traditional computer. Understanding the requirements for the application, designing the interface, and working with users are all steps that still need to be carried out.

Mobile Apps

So what’s different about building an application for a mobile device? There are five primary differences:

• Breakthroughs in component technologies. Mobile devices require multiple components that are not only smaller but more energy-efficient than those in full-size computers (laptops or desktops). For example, low-power CPUs combined with longer-life batteries, touchscreens, and Wi-Fi enable very efficient computing on a phone, which needs to do much less actual processing than their full-size counterparts.
• Sensors have unlocked the notion of context. The combination of sensors like GPS, gyroscopes, and cameras enables devices to be aware of things like time, location, velocity, direction, altitude, attitude, and temperature. Location in particular provides a host of benefits.
• Simple, purpose-built, task-oriented apps are easy to use.  Mobile apps are much narrower in scope than enterprise software and therefore easier to use. Likewise, they need to be intuitive and not require any training.
• Immediate access to data extends the value proposition.  In addition to the app providing a simpler interface on the front end, cloud-based data services provide access to data in near real-time, from virtually anywhere (e.g., banking, travel, driving directions, and investing). Having access to the cloud is needed to keep mobile device size and power use down.
• App stores have simplified acquisition.  Developing, acquiring, and managing apps has been revolutionized by app stores such as Apple’s App Store and Google Play. Standardized development processes and app requirements allow developers outside Apple and Google to create new apps with a built-in distribution channel. Average low app prices (including many of which that are free) has fueled demand.

In sum, the differences between building a mobile app and other types of software development look like this:

Building a mobile app for both iOS and Android operating systems is known as cross platform development. There are a number of third-party toolkits available for creating your app. Many will convert existing code such as HTML5, JavaScript, Ruby, C++, etc. However, if your app requires sophisticated programming, a cross platform developer kit may not meet your needs.

Responsive Web Design (RWD) focuses on making web pages render well on every device: desktop, laptop, tablet, smartphone. Through the concept of fluid layout RWD automatically adjusts the content to the device on which it is being viewed. You can find out more about responsive design here .

Build vs. Buy

When an organization decides that a new program needs to be developed, they must determine if it makes more sense to build it themselves or to purchase it from an outside company. This is the “build vs. buy” decision.

There are many advantages to purchasing software from an outside company. First, it is generally less expensive to purchase software than to build it. Second, when software is purchased, it is available much more quickly than if the package is built in-house. Software can take months or years to build. A purchased package can be up and running within a few days. Third, a purchased package has already been tested and many of the bugs have already been worked out. It is the role of a systems integrator to make various purchased systems and the existing systems at the organization work together.

There are also disadvantages to purchasing software. First, the same software you are using can be used by your competitors. If a company is trying to differentiate itself based on a business process incorporated into purchased software, it will have a hard time doing so if its competitors use the same software. Another disadvantage to purchasing software is the process of customization. If you purchase software from a vendor and then customize it, you will have to manage those customizations every time the vendor provides an upgrade. This can become an administrative headache, to say the least.

Even if an organization determines to buy software, it still makes sense to go through the same analysis as if it was going to be developed. This is an important decision that could have a long-term strategic impact on the organization.

Web Services

Chapter 3 discussed how the move to cloud computing has allowed software to be viewed as a service. One option, known as web services , allows companies to license functions provided by other companies instead of writing the code themselves. Web services can greatly simplify the addition of functionality to a website.

Suppose a company wishes to provide a map showing the location of someone who has called their support line. By utilizing Google Maps API web services , the company can build a Google Map directly into their application. Or a shoe company could make it easier for its retailers to sell shoes online by providing a shoe sizing web service that the retailers could embed right into their website.

Web services can blur the lines between “build vs. buy.” Companies can choose to build an application themselves but then purchase functionality from vendors to supplement their system.

End-User Computing (EUC)

In many organizations application development is not limited to the programmers and analysts in the information technology department. Especially in larger organizations, other departments develop their own department-specific applications. The people who build these applications are not necessarily trained in programming or application development, but they tend to be adept with computers. A person who is skilled in a particular program, such as a spreadsheet or database package, may be called upon to build smaller applications for use by their own department. This phenomenon is referred to as end-user development , or end-user computing .

End-user computing can have many advantages for an organization. First, it brings the development of applications closer to those who will use them. Because IT departments are sometimes backlogged, it also provides a means to have software created more quickly. Many organizations encourage end-user computing to reduce the strain on the IT department.

End-user computing does have its disadvantages as well. If departments within an organization are developing their own applications, the organization may end up with several applications that perform similar functions, which is inefficient, since it is a duplication of effort. Sometimes these different versions of the same application end up providing different results, bringing confusion when departments interact. End-user applications are often developed by someone with little or no formal training in programming. In these cases, the software developed can have problems that then have to be resolved by the IT department.

End-user computing can be beneficial to an organization provided it is managed. The IT department should set guidelines and provide tools for the departments who want to create their own solutions. Communication between departments can go a long way towards successful use of end-user computing.

Sidebar: Risks of EUC’s as “Shadow IT”

The Federal Home Loan Mortgage Company, better known as Freddie Mac, was fined over $100 million in 2003 in part for understating its earnings. This triggered a large-scale project to restate its financials, which involved automating financial reporting to comply with the Sarbanes-Oxley Act of 2002. Part of the restatement project found that EUCs (such as spreadsheets and databases on individual laptops) were feeding into the General Ledger. While EUCs were not the cause of Freddie Mac’s problems (they were a symptom of insufficient oversight) to have such poor IT governance in such a large company was a serious issue. It turns these EUCs were done in part to streamline the time it took to make changes to their business processes (a common complaint of IT departments in large corporations is that it takes too long to get things done). As such, these EUCs served as a form of “shadow IT” that had not been through a normal rigorous testing process.

Implementation Methodologies

Once a new system is developed or purchased, the organization must determine the best method for implementation. Convincing a group of people to learn and use a new system can be a very difficult process. Asking employees to use new software as well as follow a new business process can have far reaching effects within the organization.

There are several different methodologies an organization can adopt to implement a new system. Four of the most popular are listed below.

• Direct cutover. In the direct cutover implementation methodology, the organization selects a particular date to terminate the use of the old system. On that date users begin using the new system and the old system is unavailable. Direct cutover has the advantage of being very fast and the least expensive implementation method. However, this method has the most risk. If the new system has an operational problem or if the users are not properly prepared, it could prove disastrous for the organization.
• Pilot implementation. In this methodology a subset of the organization known as a pilot group starts using the new system before the rest of the organization. This has a smaller impact on the company and allows the support team to focus on a smaller group of individuals. Also, problems with the new software can be contained within the group and then resolved.
• Parallel operation. Parallel operations allow both the old and new systems to be used simultaneously for a limited period of time. This method is the least risky because the old system is still being used while the new system is essentially being tested. However, this is by far the most expensive methodology since work is duplicated and support is needed for both systems in full.
• Phased implementation. Phased implementation provides for different functions of the new application to be gradually implemented with the corresponding functions being turned off in the old system. This approach is more conservative as it allows an organization to slowly move from one system to another.

Your choice of an implementation methodology depends on the complexity of both the old and new systems. It also depends on the degree of risk you are willing to take.

Change Management

As new systems are brought online and old systems are phased out, it becomes important to manage the way change is implemented in the organization. Change should never be introduced in a vacuum. The organization should be sure to communicate proposed changes before they happen and plan to minimize the impact of the change that will occur after implementation. Change management is a critical component of IT oversight.

Sidebar: Mismanaging Change

Target Corporation, which operates more than 1,500 discount stores throughout the United States, opened 133 similar stores in Canada between 2013 and 2015. The company decided to implement a new Enterprise Resources Planning (ERP) system that would integrate data from vendors, customers, and do currency calculations (US Dollars and Canadian Dollars). This implementation was coincident with Target Canada’s aggressive expansion plan and stiff competition from Wal-Mart. A two-year timeline – aggressive by any standard for an implementation of this size – did not account for data errors from multiple sources that resulted in erroneous inventory counts and financial calculations. Their supply chain became chaotic and stores were plagued by not having sufficient stock of common items, which prevented the key advantage of “one-stop shopping” for customers. In early 2015, Target Canada announced it was closing all 133 stores. In sum, “This implementation broke nearly all of the cardinal sins of ERP projects. Target set unrealistic goals, didn’t leave time for testing, and neglected to train employees properly.” [1]

Maintenance

After a new system has been introduced, it enters the maintenance phase. The system is in production and is being used by the organization. While the system is no longer actively being developed, changes need to be made when bugs are found or new features are requested. During the maintenance phase, IT management must ensure that the system continues to stay aligned with business priorities and continues to run well.

Software development is about so much more than programming. It is fundamentally about solving business problems. Developing new software applications requires several steps, from the formal SDLC process to more informal processes such as agile programming or lean methodologies. Programming languages have evolved from very low-level machine-specific languages to higher-level languages that allow a programmer to write software for a wide variety of machines. Most programmers work with software development tools that provide them with integrated components to make the software development process more efficient. For some organizations, building their own software does not make the most sense. Instead, they choose to purchase software built by a third party to save development costs and speed implementation. In end-user computing, software development happens outside the information technology department. When implementing new software applications, there are several different types of implementation methodologies that must be considered.

Study Questions

• What are the steps in the SDLC methodology?
• What is RAD software development?
• What makes the lean methodology unique?
• What are three differences between second-generation and third-generation languages?
• Why would an organization consider building its own software application if it is cheaper to buy one?
• What is responsive design?
• What is the relationship between HTML and CSS in website design?
• What is the difference between the pilot implementation methodology and the parallel implementation methodology?
• What is change management?
• What are the four different implementation methodologies?
• Which software-development methodology would be best if an organization needed to develop a software tool for a small group of users in the marketing department? Why? Which implementation methodology should they use? Why?
• Doing your own research, find three programming languages and categorize them in these areas: generation, compiled vs. interpreted, procedural vs. object-oriented.
• Some argue that HTML is not a programming language. Doing your own research, find three arguments for why it is not a programming language and three arguments for why it is.
• Read more about responsive design using the link given in the text. Provide the links to three websites that use responsive design and explain how they demonstrate responsive-design behavior.

1.   Here’s a Python program for you to analyze. The code below deals with a person’s weight and height. See if you can guess what will be printed and then try running the code in a Python interpreter such as https://www.onlinegdb.com/online_python_interpreter .

2. Here’s a broken Java program for you to analyze. The code below deals with calculating tuition, multiplying the tuition rate and the number of credits taken. The number of credits is entered by the user of the program. The code below is broken and gives the incorrect answer. Review the problem below and determine what it would output if the user entered “6” for the number of credits. How would you fix the program so that it would give the correct output?

• Taken from ACC Software Solutions. "THE MANY FACES OF FAILED ERP IMPLEMENTATIONS (AND HOW TO AVOID THEM)" https://4acc.com/article/failed-erp-implementations/ ↵

Information Systems for Business and Beyond (2019) by David Bourgeois is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License , except where otherwise noted.

Share This Book

Want to create or adapt books like this? Learn more about how Pressbooks supports open publishing practices.

Dave Bourgeois and David T. Bourgeois

Please note, there is an updated edition of this book available at  https://opentextbook.site . If you are not required to use this edition for a course, you may want to check it out.

Learning Objectives

Upon successful completion of this chapter, you will be able to:

• explain the overall process of developing a new software application;
• explain the differences between software development methodologies;
• understand the different types of programming languages used to develop software;
• understand some of the issues surrounding the development of websites and mobile applications; and
• identify the four primary implementation policies.

Introduction

When someone has an idea for a new function to be performed by a computer, how does that idea become reality? If a company wants to implement a new business process and needs new hardware or software to support it, how do they go about making it happen? In this chapter, we will discuss the different methods of taking those ideas and bringing them to reality, a process known as information systems development.

Programming

As we learned in chapter 2, software is created via programming. Programming is the process of creating a set of logical instructions for a digital device to follow using a programming language. The process of programming is sometimes called “coding” because the syntax of a programming language is not in a form that everyone can understand – it is in “code.”  

The process of developing good software is usually not as simple as sitting down and writing some code. True, sometimes a programmer can quickly write a short program to solve a need. But most of the time, the creation of software is a resource-intensive process that involves several different groups of people in an organization. In the following sections, we are going to review several different methodologies for software development.

Systems-Development Life Cycle

The first development methodology we are going to review is the systems-development life cycle (SDLC). This methodology was first developed in the 1960s to manage the large software projects associated with corporate systems running on mainframes. It is a very structured and risk-averse methodology designed to manage large projects that included multiple programmers and systems that would have a large impact on the organization.

Various definitions of the SDLC methodology exist, but most contain the following phases.

• Preliminary Analysis. In this phase, a review is done of the request. Is creating a solution possible? What alternatives exist? What is currently being done about it? Is this project a good fit for our organization? A key part of this step is a feasibility analysis, which includes an analysis of the technical feasibility (is it possible to create this?), the economic feasibility (can we afford to do this?), and the legal feasibility (are we allowed to do this?). This step is important in determining if the project should even get started.
• System Analysis. In this phase, one or more system analysts work with different stakeholder groups to determine the specific requirements for the new system. No programming is done in this step. Instead, procedures are documented, key players are interviewed, and data requirements are developed in order to get an overall picture of exactly what the system is supposed to do. The result of this phase is a system-requirements document.
• System Design. In this phase, a designer takes the system-requirements document created in the previous phase and develops the specific technical details required for the system. It is in this phase that the business requirements are translated into specific technical requirements. The design for the user interface, database, data inputs and outputs, and reporting are developed here. The result of this phase is a system-design document. This document will have everything a programmer will need to actually create the system.
• Programming. The code finally gets written in the programming phase. Using the system-design document as a guide, a programmer (or team of programmers) develop the program. The result of this phase is an initial working program that meets the requirements laid out in the system-analysis phase and the design developed in the system-design phase.
• Testing. In the testing phase, the software program developed in the previous phase is put through a series of structured tests. The first is a unit test, which tests individual parts of the code for errors or bugs. Next is a system test, where the different components of the system are tested to ensure that they work together properly. Finally, the user-acceptance test allows those that will be using the software to test the system to ensure that it meets their standards. Any bugs, errors, or problems found during testing are addressed and then tested again.
• Implementation. Once the new system is developed and tested, it has to be implemented in the organization. This phase includes training the users, providing documentation, and conversion from any previous system to the new system. Implementation can take many forms, depending on the type of system, the number and type of users, and how urgent it is that the system become operational. These different forms of implementation are covered later in the chapter.
• Maintenance. This final phase takes place once the implementation phase is complete. In this phase, the system has a structured support process in place: reported bugs are fixed and requests for new features are evaluated and implemented; system updates and backups are performed on a regular basis.

The SDLC methodology is sometimes referred to as the waterfall methodology to represent how each step is a separate part of the process; only when one step is completed can another step begin. After each step, an organization must decide whether to move to the next step or not. This methodology has been criticized for being quite rigid. For example, changes to the requirements are not allowed once the process has begun. No software is available until after the programming phase.

Again, SDLC was developed for large, structured projects. Projects using SDLC can sometimes take months or years to complete. Because of its inflexibility and the availability of new programming techniques and tools, many other software-development methodologies have been developed. Many of these retain some of the underlying concepts of SDLC but are not as rigid.

Rapid Application Development

Rapid application development (RAD) is a software-development (or systems-development) methodology that focuses on quickly building a working model of the software, getting feedback from users, and then using that feedback to update the working model. After several iterations of development, a final version is developed and implemented.

The RAD methodology consists of four phases:

• Requirements Planning. This phase is similar to the preliminary-analysis, system-analysis, and design phases of the SDLC. In this phase, the overall requirements for the system are defined, a team is identified, and feasibility is determined. 
• User Design. In this phase, representatives of the users work with the system analysts, designers, and programmers to interactively create the design of the system. One technique for working with all of these various stakeholders is the so-called JAD session. JAD is an acronym for joint application development. A JAD session gets all of the stakeholders together to have a structured discussion about the design of the system. Application developers also sit in on this meeting and observe, trying to understand the essence of the requirements.
• Construction. In the construction phase, the application developers, working with the users, build the next version of the system.This is an interactive process, and changes can be made as developers are working on the program. This step is executed in parallel with the User Design step in an iterative fashion, until an acceptable version of the product is developed.
• Cutover. In this step, which is similar to the implementation step of the SDLC, the system goes live. All steps required to move from the previous state to the use of the new system are completed here.

As you can see, the RAD methodology is much more compressed than SDLC. Many of the SDLC steps are combined and the focus is on user participation and iteration. This methodology is much better suited for smaller projects than SDLC and has the added advantage of giving users the ability to provide feedback throughout the process. SDLC requires more documentation and attention to detail and is well suited to large, resource-intensive projects. RAD makes more sense for smaller projects that are less resource-intensive and need to be developed quickly.

Agile Methodologies

Agile methodologies are a group of methodologies that utilize incremental changes with a focus on quality and attention to detail. Each increment is released in a specified period of time (called a time box), creating a regular release schedule with very specific objectives. While considered a separate methodology from RAD, they share some of the same principles: iterative development, user interaction, ability to change. The agile methodologies are based on the “ Agile Manifesto ,” first released in 2001.

The characteristics of agile methods include:

• small cross-functional teams that include development-team members and users; 
• daily status meetings to discuss the current state of the project;
• short time-frame increments (from days to one or two weeks) for each change to be completed; and
• at the end of each iteration, a working project is completed to demonstrate to the stakeholders.

The goal of the agile methodologies is to provide the flexibility of an iterative approach while ensuring a quality product.

Lean Methodology

One last methodology we will discuss is a relatively new concept taken from the business bestseller The Lean Startup , by Eric Reis. In this methodology, the focus is on taking an initial idea and developing a minimum viable product (MVP). The MVP is a working software application with just enough functionality to demonstrate the idea behind the project. Once the MVP is developed, it is given to potential users for review. Feedback on the MVP is generated in two forms: (1) direct observation and discussion with the users, and (2) usage statistics gathered from the software itself. Using these two forms of feedback, the team determines whether they should continue in the same direction or rethink the core idea behind the project, change the functions, and create a new MVP. This change in strategy is called a pivot. Several iterations of the MVP are developed, with new functions added each time based on the feedback, until a final product is completed.

The biggest difference between the lean methodology and the other methodologies is that the full set of requirements for the system are not known when the project is launched. As each iteration of the project is released, the statistics and feedback gathered are used to determine the requirements. The lean methodology works best in an entrepreneurial environment where a company is interested in determining if their idea for a software application is worth developing.

Sidebar: The Quality Triangle

When developing software, or any sort of product or service, there exists a tension between the developers and the different stakeholder groups, such as management, users, and investors. This tension relates to how quickly the software can be developed (time), how much money will be spent (cost), and how well it will be built (quality). The quality triangle is a simple concept. It states that for any product or service being developed, you can only address two of the following: time, cost, and quality.

So what does it mean that you can only address two of the three? It means that you cannot complete a low-cost, high-quality project in a small amount of time. However, if you are willing or able to spend a lot of money, then a project can be completed quickly with high-quality results (through hiring more good programmers). If a project’s completion date is not a priority, then it can be completed at a lower cost with higher-quality results. Of course, these are just generalizations, and different projects may not fit this model perfectly. But overall, this model helps us understand the tradeoffs that we must make when we are developing new products and services.

Programming Languages

As I noted earlier, software developers create software using one of several programming languages. A programming language is an artificial language that provides a way for a programmer to create structured code to communicate logic in a format that can be executed by the computer hardware. Over the past few decades, many different types of programming languages have evolved to meet many different needs. One way to characterize programming languages is by their “generation.”

Generations of Programming Languages

Early languages were specific to the type of hardware that had to be programmed; each type of computer hardware had a different low-level programming language (in fact, even today there are differences at the lower level, though they are now obscured by higher-level programming languages). In these early languages, very specific instructions had to be entered line by line – a tedious process.

First-generation languages are called machine code. In machine code, programming is done by directly setting actual ones and zeroes (the bits) in the program using binary code. Here is an example program  that adds 1234 and 4321  using machine language:

Assembly language is the second-generation language. Assembly language gives english-like phrases to the machine-code instructions, making it easier to program. An assembly-language program must be run through an assembler, which converts it into machine code. Here is an example program t hat adds 1234 and 4321 using assembly language:

Third-generation languages are not specific to the type of hardware on which they run and are much more like spoken languages. Most third-generation languages must be compiled, a process that converts them into machine code. Well-known third-generation languages include BASIC, C, Pascal, and Java. Here is an example using BASIC:

Fourth-generation languages are a class of programming tools that enable fast application development using intuitive interfaces and environments. Many times, a fourth-generation language has a very specific purpose, such as database interaction or report-writing. These tools can be used by those with very little formal training in programming and allow for the quick development of applications and/or functionality. Examples of fourth-generation languages include: Clipper, FOCUS, FoxPro, SQL, and SPSS.

Why would anyone want to program in a lower-level language when they require so much more work? The answer is similar to why some prefer to drive stick-shift automobiles instead of automatic transmission: control and efficiency. Lower-level languages, such as assembly language, are much more efficient and execute much more quickly. You have finer control over the hardware as well. Sometimes, a combination of higher- and lower-level languages are mixed together to get the best of both worlds: the programmer will create the overall structure and interface using a higher-level language but will use lower-level languages for the parts of the program that are used many times or require more precision.

Compiled vs. Interpreted

Besides classifying a program language based on its generation, it can also be classified by whether it is compiled or interpreted. As we have learned, a computer language is written in a human-readable form. In a compiled language, the program code is translated into a machine-readable form called an executable that can be run on the hardware. Some well-known compiled languages include C, C++, and COBOL.

An interpreted language is one that requires a runtime program to be installed in order to execute. This runtime program then interprets the program code line by line and runs it. Interpreted languages are generally easier to work with but also are slower and require more system resources. Examples of popular interpreted languages include BASIC, PHP, PERL, and Python. The web languages of HTML and Javascript would also be considered interpreted because they require a browser in order to run.

The Java programming language is an interesting exception to this classification, as it is actually a hybrid of the two. A program written in Java is partially compiled to create a program that can be understood by the Java Virtual Machine (JVM). Each type of operating system has its own JVM which must be installed, which is what allows Java programs to run on many different types of operating systems.

Procedural vs. Object-Oriented

A procedural programming language is designed to allow a programmer to define a specific starting point for the program and then execute sequentially. All early programming languages worked this way. As user interfaces became more interactive and graphical, it made sense for programming languages to evolve to allow the user to define the flow of the program. The object-oriented programming language is set up so that the programmer defines “objects” that can take certain actions based on input from the user. In other words, a procedural program focuses on the sequence of activities to be performed; an object-oriented program focuses on the different items being manipulated.

For example, in a human-resources system, an “EMPLOYEE” object would be needed. If the program needed to retrieve or set data regarding an employee, it would first create an employee object in the program and then set or retrieve the values needed. Every object has properties, which are descriptive fields associated with the object. In the example below, an employee object has the properties “Name”, “Employee number”, “Birthdate” and “Date of hire”. An object also has “methods”, which can take actions related to the object. In the example, there are two methods. The first is “ComputePay()”, which will return the current amount owed the employee. The second is “ListEmployees()”, which will retrieve a list of employees who report to this employee.

Figure: An example of an object

Sidebar: What is COBOL?

If you have been around business programming very long, you may have heard about the COBOL programming language. COBOL is a procedural, compiled language that at one time was the primary programming language for business applications. Invented in 1959 for use on large mainframe computers, COBOL is an abbreviation of common business-oriented language. With the advent of more efficient programming languages, COBOL is now rarely seen outside of old, legacy applications.

Programming Tools

To write a program, a programmer needs little more than a text editor and a good idea. However, to be productive, he or she must be able to check the syntax of the code, and, in some cases, compile the code. To be more efficient at programming, additional tools, such as an integrated development environment (IDE) or computer-aided software-engineering (CASE) tools, can be used.

Integrated Development Environment

For most programming languages, an IDE can be used. An IDE provides a variety of tools for the programmer, and usually includes:

• an editor for writing the program that will color-code or highlight keywords from the programming language;
• a help system that gives detailed documentation regarding the programming language;
• a compiler/interpreter, which will allow the programmer to run the program;
• a debugging tool, which will provide the programmer details about the execution of the program in order to resolve problems in the code; and
• a check-in/check-out mechanism, which allows for a team of programmers to work together on a project and not write over each other’s code changes.

Probably the most popular IDE software package right now is Microsoft’s Visual Studio . Visual Studio is the IDE for all of Microsoft’s programming languages, including Visual Basic, Visual C++, and Visual C#.

While an IDE provides several tools to assist the programmer in writing the program, the code still must be written. Computer-aided software-engineering (CASE) tools allow a designer to develop software with little or no programming. Instead, the CASE tool writes the code for the designer. CASE tools come in many varieties, but their goal is to generate quality code based on input created by the designer.

Sidebar: Building a Website

In the early days of the World Wide Web, the creation of a website required knowing how to use hypertext markup language (HTML). Today, most websites are built with a variety of tools, but the final product that is transmitted to a browser is still HTML. HTML, at its simplest, is a text language that allows you to define the different components of a web page. These definitions are handled through the use of HTML tags, which consist of text between brackets. For example, an HTML tag can tell the browser to show a word in italics, to link to another web page, or to insert an image. In the example below, some text is being defined as a heading while other text is being emphasized.

While HTML is used to define the components of a web page, cascading style sheets (CSS) are used to define the styles of the components on a page. The use of CSS allows the style of a website to be set and stay consistent throughout. For example, if the designer wanted all first-level headings (h1) to be blue and centered, he or she could set the “h1” style to match. The following example shows how this might look.

The combination of HTML and CSS can be used to create a wide variety of formats and designs and has been widely adopted by the web-design community. The standards for HTML are set by a governing body called the  World Wide Web Consortium . The current version of HTML is HTML 5, which includes new standards for video, audio, and drawing.

When developers create a website, they do not write it out manually in a text editor. Instead, they use web design tools that generate the HTML and CSS for them. Tools such as Adobe Dreamweaver allow the designer to create a web page that includes images and interactive elements without writing a single line of code. However, professional web designers still need to learn HTML and CSS in order to have full control over the web pages they are developing.

Build vs. Buy

When an organization decides that a new software program needs to be developed, they must determine if it makes more sense to build it themselves or to purchase it from an outside company. This is the “build vs. buy” decision.

There are many advantages to purchasing software from an outside company. First, it is generally less expensive to purchase a software package than to build it. Second, when a software package is purchased, it is available much more quickly than if the package is built in-house. Software applications can take months or years to build; a purchased package can be up and running within a month. A purchased package has already been tested and many of the bugs have already been worked out. It is the role of a systems integrator to make various purchased systems and the existing systems at the organization  work together .

There are also disadvantages to purchasing software. First, the same software you are using can be used by your competitors. If a company is trying to differentiate itself based on a business process that is in that purchased software, it will have a hard time doing so if its competitors use the same software. Another disadvantage to purchasing software is the process of customization. If you purchase a software package from a vendor and then customize it, you will have to manage those customizations every time the vendor provides an upgrade. This can become an administrative headache, to say the least!

Even if an organization determines to buy software, it still makes sense to go through many of the same analyses that they would do if they were going to build it themselves. This is an important decision that could have a long-term strategic impact on the organization.

Web Services

As we saw in chapter 3, the move to cloud computing has allowed software to be looked at as a service. One option companies have these days is to license functions provided by other companies instead of writing the code themselves. These are called web services, and they can greatly simplify the addition of functionality to a website.

For example, suppose a company wishes to provide a map showing the location of someone who has called their support line. By utilizing Google Maps API web services , they can build a Google Map right into their application. Or a shoe company could make it easier for its retailers to sell shoes online by providing a shoe-size web service that the retailers could embed right into their website.

Web services can blur the lines between “build vs. buy.” Companies can choose to build a software application themselves but then purchase functionality from vendors to supplement their system.

End-User Computing

In many organizations, application development is not limited to the programmers and analysts in the information-technology department. Especially in larger organizations, other departments develop their own department-specific applications. The people who build these are not necessarily trained in programming or application development, but they tend to be adept with computers. A person, for example, who is skilled in a particular software package, such as a spreadsheet or database package, may be called upon to build smaller applications for use by his or her own department. This phenomenon is referred to as end-user development, or end-user computing.

End-user computing can have many advantages for an organization. First, it brings the  development of  applications closer to those who will use them. Because IT departments are sometimes quite backlogged, it also provides a means to have software created  more quickly . Many organizations encourage end-user computing to reduce the strain on the IT department.

End-user computing does have its disadvantages as well. If departments within an organization are developing their own applications, the organization may end up with several applications that perform similar functions, which is inefficient, since it is a duplication of effort. Sometimes, these different versions of the same application end up providing different results, bringing confusion when departments interact. These applications are often developed by someone with little or no formal training in programming. In these cases, the software developed can have problems that then have to be resolved by the IT department.

End-user computing can be beneficial to an organization, but it should be managed. The IT department should set guidelines and provide tools for the departments who want to create their own solutions. Communication between departments will go a long way towards successful use of end-user computing.

Sidebar: Building a Mobile App

In many ways, building an application for a mobile device is exactly the same as building an application for a traditional computer. Understanding the requirements for the application, designing the interface, working with users – all of these steps still need to be carried out.

So what’s different about building an application for a mobile device? In some ways, mobile applications are more limited. An application running on a mobile device must be designed to be functional on a smaller screen. Mobile applications should be designed to use fingers as the primary pointing device. Mobile devices generally have less available memory, storage space, and processing power.

Mobile applications also have many advantages over applications built for traditional computers. Mobile applications have access to the functionality of the mobile device, which usually includes features such as geolocation data, messaging, the camera, and even a gyroscope.

One of the most important questions regarding development for mobile devices is this: Do we want to develop an app at all? A mobile app is an expensive proposition, and it will only run on one type of mobile device at a time. For example, if you create an iPhone app, users with Android phones are out of luck. Each app takes several thousand dollars to create, so this may not be the best use of your funds.

Many organizations are moving away from developing a specific app for a mobile device and are instead making their websites more functional on mobile devices. Using a web-design framework called responsive design, a website can be made highly functional no matter what type of device is browsing it. With a responsive website, images resize themselves based on the size of the device’s screen, and text flows and sizes itself properly for optimal viewing. You can find out more about responsive design here .

Implementation Methodologies

Once a new system is developed (or purchased), the organization must determine the best method for implementing it. Convincing a group of people to learn and use a new system can be a very difficult process. Using new software, and the business processes it gives rise to, can have far-reaching effects within the organization.

There are several different methodologies an organization can adopt to implement a new system. Four of the most popular are listed below.

• Direct cutover. In the direct-cutover implementation methodology, the organization selects a particular date that the old system is not going to be used anymore. On that date, the users begin using the new system and the old system is unavailable. The advantages to using this methodology are that it is very fast and the least expensive. However, this method is the riskiest as well. If the new system has an operational problem or if the users are not properly prepared, it could prove disastrous for the organization.
• Pilot implementation. In this methodology, a subset of the organization (called a pilot group) starts using the new system before the rest of the organization. This has a smaller impact on the company and allows the support team to focus on a smaller group of individuals.
• Parallel operation. With parallel operation, the old and new systems are used simultaneously for a limited period of time. This method is the least risky because the old system is still being used while the new system is essentially being tested. However, this is by far the most expensive methodology since work is duplicated and support is needed for both systems in full.
• Phased implementation. In phased implementation, different functions of the new application are used as functions from the old system are turned off. This approach allows an organization to slowly move from one system to another.

Which of these implementation methodologies to use depends on the complexity and importance of the old and new systems.

Change Management

As new systems are brought online and old systems are phased out, it becomes important to manage the way change is implemented in the organization. Change should never be introduced in a vacuum. The organization should be sure to communicate proposed changes before they happen and plan to minimize the impact of the change that will occur after implementation. Change management is a critical component of IT oversight.

Maintenance

Once a new system has been introduced, it enters the maintenance phase. In this phase, the system is in production and is being used by the organization. While the system is no longer actively being developed, changes need to be made when bugs are found or new features are requested. During the maintenance phase, IT management must ensure that the system continues to stay aligned with business priorities and continues to run well.

Software development is about so much more than programming. Developing new software applications requires several steps, from the formal SDLC process to more informal processes such as agile programming or lean methodologies. Programming languages have evolved from very low-level machine-specific languages to higher-level languages that allow a programmer to write software for a wide variety of machines. Most programmers work with software development tools that provide them with integrated components to make the software development process more efficient. For some organizations, building their own software applications does not make the most sense; instead, they choose to purchase software built by a third party to save development costs and speed implementation. In end-user computing, software development happens outside the information technology department. When implementing new software applications, there are several different types of implementation methodologies that must be considered.

Study Questions

• What are the steps in the SDLC methodology?
• What is RAD software development?
• What makes the lean methodology unique?
• What are three differences between second-generation and third-generation languages?
• Why would an organization consider building its own software application if it is cheaper to buy one?
• What is responsive design?
• What is the relationship between HTML and CSS in website design?
• What is the difference between the pilot implementation methodology and the parallel implementation methodology?
• What is change management?
• What are the four different implementation methodologies?
• Which software-development methodology would be best if an organization needed to develop a software tool for a small group of users in the marketing department? Why? Which implementation methodology should they use? Why?
• Doing your own research, find three programming languages and categorize them in these areas: generation, compiled vs. interpreted, procedural vs. object-oriented.
• Some argue that HTML is not a programming language. Doing your own research, find three arguments for why it is not a programming language and three arguments for why it is.
• Read more about responsive design using the link given in the text. Provide the links to three websites that use responsive design and explain how they demonstrate responsive-design behavior.

Information Systems for Business and Beyond Copyright © 2014 by Dave Bourgeois and David T. Bourgeois is licensed under a Creative Commons Attribution 4.0 International License , except where otherwise noted.

Information Systems Development Methodologies

• First Online: 01 January 2014

Cite this chapter

• Pedro Isaias 3 &
• Tomayess Issa 4  

2254 Accesses

An information system (IS) is commonly known as a system whose central element is information. Its main purpose is to store, treat, and provide information with the intention to support specific functions or processes within an organization.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as EPUB and PDF
• Read on any device
• Instant download
• Own it forever
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Definition available at Lecture notes in information technology http://www.ier-institute.org/2070-1918/lnit25/lnit%20v25/i.pdf .

Abbas, N., Gravell, A., & Wills, G. (2008). Historical roots of Agile methods: Where did “Agile thinking” come from? In P. Abrahamsson, R. Baskerville, K. Conboy, B. Fitzgerald, L. Morgan, & X. Wang (Eds.), Agile processes in software engineering and extreme programming (pp. 94–103). Berlin: Springer.

Chapter   Google Scholar  

Abrahamsson, P., Conboy, K., & Wang, X. (2009). “Lots done, more to do”: The current state of Agile systems development research. European Journal of Information Systems, 18 , 281–284.

Article   Google Scholar  

Adman, P., & Warren, L. (2000). Participatory sociotechnical design of organizations and information systems—An adaptation of ETHICS methodology. Journal of Information Technology, 15 , 39–51.

Allen, B. (2000). Individual differences and the conundrums of user-centered design: Two experiments. Journal of the American Society for Information Science, 51 (6), 501–520.

Aouad, G. F., Kirkham, J. A., Brandon, P. S., Brown, F. E., Cooper, G. S., Ford, S. S., et al. (1993). Information modelling in the construction industry: The information engineering approach. Construction Management & Economics, 11 (5), 384–397.

Ashworth, C. M. (1988). Structured systems analysis and design method (SSADM). Information and Software Technology, 30 (3), 153–163.

Avison, D., & Taylor, V. (1997). Information systems development methodologies: A classification according to problem situation. Journal of Information Technology, 12 , 73–81.

Avison, D., Wood-Harper, A., Vidgen, R., & Wood, J. (1998). A further exploration into information systems development: The evolution of Multiview2. Information Technology & People, 11 (2), 124–139.

Avison, D., & Wood-Harper, T. (2003). Bringing social and organisational issues into information systems development: The story of multiview. In S. Clarke, E. Coakes, M. G. Hunter, & A. Wenn (Eds.), Socio-technical and human cognition elements of information systems (pp. 5–21). Hershey: Information Science Publishing.

Google Scholar  

Avison, D., & Fitzgerald, G. (2003). Where now for development methodologies? Communications of the ACM, 46 (1), 79–82.

Aydin, M., Harmsen, F., Van Slooten, K., & Stegwee, R. (2004). An Agile information systems development method in use. Turkish Journal of Electronic Engineering, 12 , 127–138.

Britts, W. (2011). The relationship between organizational and national culture and the use and effectiveness of systems development methodologies (Master’s thesis, North-West University, South Africa). Retrieved from http://dspace.nwu.ac.za/handle/10394/9165 .

Cameron, J. R. (1986). An overview of JSD. IEEE Transactions on Software Engineering, 12 (2), 222–240.

Checkland, P. (2000). Soft systems methodology: A thirty year retrospective. Systems Research and Behavioral Science, 17 , 11–58.

Conboy, K. (2009). Agility from first principles: Reconstructing the concept of Agility in information systems development. Information Systems Research, 20 (3), 329–354.

Edwards, H. M., Thompson, J. B., & Smith, P. (1989). Results of survey of use of SSADM in commercial and government sectors in United Kingdom. Information and Software Technology, 31 (1), 21–28.

Gasson, S. (1995). The role of methodologies in IT-related organizational change. In Proceedings of BCS Specialist Group on IS Methodologies, 3rd Annual Conference: The Application of Methodologies in Industrial and Business Change, pp. 1–14.

Goodland, M., & Riha, K. (1999). SSADM—An introduction. Retrieved from http://www.dcs.bbk.ac.uk/~steve/1/index.htm

Gould, J., & Lewis, C. (1985). Designing for usability: Key principles and what designers think. Communications of the ACM, 28 (3), 300–311.

Gulliksen, J., Göransson, B., Boivie, I., Blomkvist, S., Persson, J., & Cajander, A. (2003). Key principles for user-centred systems design. Behaviour and Information Technology, 22 (6), 397–409.

Hanani, M., & Shoval, P. (1986). A combined methodology for Information Systems analysis and design based on ISAC and NIAM. Information Systems, 11 (3), 245–253.

Hardman, J., & Paucar-Caceres, A. (2011). A soft systems methodology (SSM) based framework for evaluating managed learning environments. Systemic Practice and Action Research, 24 (2), 165–185.

Hevner, A., March, S., Park, J., & Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28 (1), 75–105.

Highsmith, J. (2002). Agile software development ecosystems . Boston: Addison-Wesley.

Hirschheim, R., & Klein, H. K. (1994). Realizing emancipator principles in information-systems development—the case for ETHICS. MIS Quarterly, 18 (1), 83–109.

Hogan, P., & Raja, M. K. (1997). Information engineering implementation in organizations: A study of factors affecting success. Journal of Information Technology Management, 8 (3), 33–44.

Jackson, M. (1992). Jackson development methods: JSP and JSD. In J. Marciniak (Ed.), Wiley encyclopaedia of software engineering (pp. 585–593). New York: Wiley.

Jackson, M. (2000). The origins of JSP and JSD: A personal recollection. IEEE Annals of Software Engineering, 22 (2), 61–63, 66.

Jackson, M. (2002). Jackson development methods. In J. Marciniak (Ed.), Wiley encyclopaedia of software engineering . New York: Wiley.

Litan, D., Apostu, A., Copcea, L., & Teohari, M. (2011). Technologies for development of the information systems: From ERP to e-government. International Journal of Applied Mathematics and Informatics, 5 (2), 137–152.

Manteghi, N., & Jahromi, S. (2012). Designing accounting information system using SSADM1 case study: South fars power generation management company (S.F.P.G.M.C.). Procedia Technology, 1 , 308–312.

Mao, J.-Y., Vredenburgh, K., Smith, P. W., & Carey, T. (2005). The state of user-centered design practice. Communications of the ACM, 48 (3), 105–109.

Mumford, E. (1993). The ETHICS approach. Communications of the ACM, 36 (6), 82.

Mumford, E. (2000). A socio-technical approach to systems design. Requirements Engineering, 5 , 125–133.

Nilsson, A., (1989). Information Systems development: A frame of reference and classifications. In Proceedings of the First International Conference on Advanced Information Systems Engineering, CAiSE’89.

Paelke, V., & Nebe, K. (2008). Integrating Agile methods for mixed reality design space exploration. In Proceedings of the 7th ACM Conference on Designing Interactive Systems, ACM , pp. 240–249.

Patel, N. V. (1995). Application of Soft systems methodology to the real world process of teaching and learning. International Journal of Educational Management, 9 (1), 13–23.

Roberts, S. (2010). Introduction to information engineering . Retrieved from http://www.robots.ox.ac.uk/~sjrob/ox_teach.html

Rodríguez-Ulloa, R. A., Montbrun, A., & Martínez-Vicente, S. (2011). Soft system dynamics methodology in action: A study of the problem of citizen insecurity in an Argentinean province. Systemic Practice and Action Research, 24 , 275–323.

Rohde, F. (1995). An ontological evaluation of Jackson’s system development model. Australasian Journal of Information Systems, 2 (2), 77–87.

Sánchez, A., & Mejía, A. (2008). Learning to support learning together: An experience with the Soft systems methodology. Educational Action Research, 16 (1), 109–124.

Savage, A., & Mingers, J. (1996). A framework for linking soft systems methodology (SSM) and Jackson system development (JSD). lnfo Systems Journal, 6 , 109–129.

Schumacher, M. (2001). The use of SSADM (structured systems analysis and design methodology) as a standard methodology on information systems projects . Munich: GRIN Publishing GmbH. Retrieved from http://www.grin.com/en/e-book/106034/the-use-of-ssadm-structured-systems-analysis-and-design-methodology-as

Sharma, S., Sarkar, D., & Gupta, D. (2012). Agile processes and methodologies: A conceptual study. International Journal on Computer Science and Engineering, 4 (5), 892–898.

Tajino, A., James, R., & Kijima, K. (2005). Beyond needs analysis: Soft systems methodology for meaningful collaboration in EAP course design. Journal of English for Academic Purposes, 4 , 27–42.

Tumbas, P., & Matkovic, P. (2006). Agile vs traditional methodologies in developing information systems. Managament Information Systems, 1 , 15–24.

Venturi, G., & Troost, J. (2004). Survey on user centred design integration in the industry. ACM International Conference Proceedings of the Third Nordic Conference on Human-Computer Interaction (pp. 449–452).

VersionOne (2013). 8th Annual State of Agile development survey. Retrieved from http://stateofagile.versionone.com/

Vidgen, R. (2002). Constructing a web information system development methodology. Info Systems Journal, 12 , 247–261.

Vredenburg, K., Mao, J., Smith, P., & Carey, T. (2002). A survey of user-centered design practice. In Proceedings of CHI’2002 Conference on Human Factors in Computing Systems (Amsterdam) (pp. 471–478).

Wallach, D., & Scholz, S. (2012). User-centered design: Why and how to put users first in software development. In A. Maedche, A. Botzenhardt, & L. Neer (Eds.), Software for people—Fundamentals, trends and best practices (pp. 11–38). Berlin: Springer.

Wieringa, R. J. (1996) . Requirements engineering: Frameworks for understanding . Wiley, New York.

Wong, E., & Tate, G. (1994). A study of user participation in information systems development. Journal of Information Technology, 9 , 51–60.

Zaied, A., Aal, S., & Hassan, M. (2003). Rule-based expert systems for selecting information systems development methodologies. International Journal of Intelligent Systems and Applications, 9 , 19–26.

Zarvic, N., & Daneva. M. (2006). Challenges and solutions in planning information systems for networked value constellations. In M. Weske & M. Nüttgens (Eds.), Proceedings of the EMISA 2006 Workshop: Vol. P-95 of LNI - Lecture Notes in Informatics (pp. 119–131). Hamburg: Gesellschaft für Informatik.

Download references

Author information

Authors and affiliations.

Universidade Aberta, Lisbon, Portugal

Pedro Isaias

Curtin University School of Information Systems, Perth, WA, Australia

Tomayess Issa

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Pedro Isaias .

Rights and permissions

Reprints and permissions

Copyright information

© 2015 Springer Science+Business Media New York

About this chapter

Isaias, P., Issa, T. (2015). Information Systems Development Methodologies. In: High Level Models and Methodologies for Information Systems. Springer, New York, NY. https://doi.org/10.1007/978-1-4614-9254-2_3

Download citation

DOI : https://doi.org/10.1007/978-1-4614-9254-2_3

Published : 25 September 2014

Publisher Name : Springer, New York, NY

Print ISBN : 978-1-4614-9253-5

Online ISBN : 978-1-4614-9254-2

eBook Packages : Humanities, Social Sciences and Law Education (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

Learn Creative Problem Solving Techniques to Stimulate Innovation in Your Organization

By Kate Eby | October 20, 2017 (updated August 27, 2021)

• Share on Facebook
• Share on LinkedIn

Link copied

In today’s competitive business landscape, organizations need processes in place to make strong, well-informed, and innovative decisions. Problem solving - in particular creative problem solving (CPS) - is a key skill in learning how to accurately identify problems and their causes, generate potential solutions, and evaluate all the possibilities to arrive at a strong corrective course of action. Every team in any organization, regardless of department or industry, needs to be effective, creative, and quick when solving problems. 

In this article, we’ll discuss traditional and creative problem solving, and define the steps, best practices, and common barriers associated. After that, we’ll provide helpful methods and tools to identify the cause(s) of problematic situations, so you can get to the root of the issue and start to generate solutions. Then, we offer nearly 20 creative problem solving techniques to implement at your organization, or even in your personal life. Along the way, experts weigh in on the importance of problem solving, and offer tips and tricks. 

What Is Problem Solving and Decision Making?

Problem solving is the process of working through every aspect of an issue or challenge to reach a solution. Decision making is choosing one of multiple proposed solutions  — therefore, this process also includes defining and evaluating all potential options. Decision making is often one step of the problem solving process, but the two concepts are distinct. 

Collective problem solving is problem solving that includes many different parties and bridges the knowledge of different groups. Collective problem solving is common in business problem solving because workplace decisions typically affect more than one person. 

Problem solving, especially in business, is a complicated science. Not only are business conflicts multifaceted, but they often involve different personalities, levels of authority, and group dynamics. In recent years, however, there has been a rise in psychology-driven problem solving techniques, especially for the workplace. In fact, the psychology of how people solve problems is now studied formally in academic disciplines such as psychology and cognitive science.

Joe Carella is the Assistant Dean for Executive Education at the University of Arizona . Joe has over 20 years of experience in helping executives and corporations in managing change and developing successful business strategies. His doctoral research and executive education engagements have seen him focus on corporate strategy, decision making and business performance with a variety of corporate clients including Hershey’s, Chevron, Fender Musical Instruments Corporation, Intel, DP World, Essilor, BBVA Compass Bank.

He explains some of the basic psychology behind problem solving: “When our brain is engaged in the process of solving problems, it is engaged in a series of steps where it processes and organizes the information it receives while developing new knowledge it uses in future steps. Creativity is embedded in this process by incorporating diverse inputs and/or new ways of organizing the information received.”

Laura MacLeod is a Professor of Social Group Work at City University of New York, and the creator of From The Inside Out Project® , a program that coaches managers in team leadership for a variety of workplaces. She has a background in social work and over two decades of experience as a union worker, and currently leads talks on conflict resolution, problem solving, and listening skills at conferences across the country. 

MacLeod thinks of problem solving as an integral practice of successful organizations. “Problem solving is a collaborative process — all voices are heard and connected, and resolution is reached by the group,” she says. “Problems and conflicts occur in all groups and teams in the workplace, but if leaders involve everyone in working through, they will foster cohesion, engagement, and buy in. Everybody wins.”

10 tips that will make you more productive.

Uncover the top three factors that are killing your productivity and 10 tips to help you overcome them.

Download the free e-book to overcome my productivity killers

Project Management Guide

Your one-stop shop for everything project management

Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.

View the guide

What Is the First Step in Solving a Problem?

Although problem solving techniques vary procedurally, experts agree that the first step in solving a problem is defining the problem. Without a clear articulation of the problem at stake, it is impossible to analyze all the key factors and actors, generate possible solutions, and then evaluate them to pick the best option. 

Dr. Elliott Jaffa is a behavioral and management psychologist with over 25 years of problem solving training and management experience. “Start with defining the problem you want to solve,” he says, “And then define where you want to be, what you want to come away with.” He emphasizes these are the first steps in creating an actionable, clear solution. 

Bryan Mattimore is Co-Founder of Growth Engine, an 18-year old innovation agency based in Norwalk, CT. Bryan has facilitated over 1,000 ideation sessions and managed over 200 successful innovation projects leading to over $3 billion in new sales. His newest book is 21 Days to a Big Idea . When asked about the first critical component to successful problem solving, Mattimore says, “Defining the challenge correctly, or ‘solving the right problem’ … The three creative techniques we use to help our clients ‘identify the right problem to be solved’ are questioning assumptions, 20 questions, and problem redefinition. A good example of this was a new product challenge from a client to help them ‘invent a new iron. We got them to redefine the challenge as first: a) inventing new anti-wrinkle devices, and then b) inventing new garment care devices.”

What Are Problem Solving Skills?

To understand the necessary skills in problem solving, you should first understand the types of thinking often associated with strong decision making. Most problem solving techniques look for a balance between the following binaries:

• Convergent vs. Divergent Thinking: Convergent thinking is bringing together disparate information or ideas to determine a single best answer or solution. This thinking style values logic, speed, and accuracy, and leaves no chance for ambiguity. Divergent thinking is focused on generating new ideas to identify and evaluate multiple possible solutions, often uniting ideas in unexpected combinations. Divergent thinking is characterized by creativity, complexity, curiosity, flexibility, originality, and risk-taking.
• Pragmatics vs. Semantics: Pragmatics refer to the logic of the problem at hand, and semantics is how you interpret the problem to solve it. Both are important to yield the best possible solution.
• Mathematical vs. Personal Problem Solving: Mathematical problem solving involves logic (usually leading to a single correct answer), and is useful for problems that involve numbers or require an objective, clear-cut solution. However, many workplace problems also require personal problem solving, which includes interpersonal, collaborative, and emotional intuition and skills. 

The following basic methods are fundamental problem solving concepts. Implement them to help balance the above thinking models.

• Reproductive Thinking: Reproductive thinking uses past experience to solve a problem. However, be careful not to rely too heavily on past solutions, and to evaluate current problems individually, with their own factors and parameters. 
• Idea Generation: The process of generating many possible courses of action to identify a solution. This is most commonly a team exercise because putting everyone’s ideas on the table will yield the greatest number of potential solutions. 

However, many of the most critical problem solving skills are “soft” skills: personal and interpersonal understanding, intuitiveness, and strong listening. 

Mattimore expands on this idea: “The seven key skills to be an effective creative problem solver that I detail in my book Idea Stormers: How to Lead and Inspire Creative Breakthroughs are: 1) curiosity 2) openness 3) a willingness to embrace ambiguity 4) the ability to identify and transfer principles across categories and disciplines 5) the desire to search for integrity in ideas, 6) the ability to trust and exercise “knowingness” and 7) the ability to envision new worlds (think Dr. Seuss, Star Wars, Hunger Games, Harry Potter, etc.).”

“As an individual contributor to problem solving it is important to exercise our curiosity, questioning, and visioning abilities,” advises Carella. “As a facilitator it is essential to allow for diverse ideas to emerge, be able to synthesize and ‘translate’ other people’s thinking, and build an extensive network of available resources.”

MacLeod says the following interpersonal skills are necessary to effectively facilitate group problem solving: “The abilities to invite participation (hear all voices, encourage silent members), not take sides, manage dynamics between the monopolizer, the scapegoat, and the bully, and deal with conflict (not avoiding it or shutting down).” 

Furthermore, Jaffa explains that the skills of a strong problem solver aren’t measurable. The best way to become a creative problem solver, he says, is to do regular creative exercises that keep you sharp and force you to think outside the box. Carella echoes this sentiment: “Neuroscience tells us that creativity comes from creating novel neural paths. Allow a few minutes each day to exercise your brain with novel techniques and brain ‘tricks’ – read something new, drive to work via a different route, count backwards, smell a new fragrance, etc.”

What Is Creative Problem Solving? History, Evolution, and Core Principles

Creative problem solving (CPS) is a method of problem solving in which you approach a problem or challenge in an imaginative, innovative way. The goal of CPS is to come up with innovative solutions, make a decision, and take action quickly. Sidney Parnes and Alex Osborn are credited with developing the creative problem solving process in the 1950s. The concept was further studied and developed at SUNY Buffalo State and the Creative Education Foundation. 

The core principles of CPS include the following:

• Balance divergent and convergent thinking
• Ask problems as questions
• Defer or suspend judgement
• Focus on “Yes, and…” rather than “No, but…”

According to Carella, “Creative problem solving is the mental process used for generating innovative and imaginative ideas as a solution to a problem or a challenge. Creative problem solving techniques can be pursued by individuals or groups.”

When asked to define CPS, Jaffa explains that it is, by nature, difficult to create boundaries for. “Creative problem solving is not cut and dry,” he says, “If you ask 100 different people the definition of creative problem solving, you’ll get 100 different responses - it’s a non-entity.”

Business presents a unique need for creative problem solving. Especially in today’s competitive landscape, organizations need to iterate quickly, innovate with intention, and constantly be at the cutting-edge of creativity and new ideas to succeed. Developing CPS skills among your workforce not only enables you to make faster, stronger in-the-moment decisions, but also inspires a culture of collaborative work and knowledge sharing. When people work together to generate multiple novel ideas and evaluate solutions, they are also more likely to arrive at an effective decision, which will improve business processes and reduce waste over time. In fact, CPS is so important that some companies now list creative problem solving skills as a job criteria.

MacLeod reiterates the vitality of creative problem solving in the workplace. “Problem solving is crucial for all groups and teams,” she says. “Leaders need to know how to guide the process, hear all voices and involve all members - it’s not easy.”

“This mental process [of CPS] is especially helpful in work environments where individuals and teams continuously struggle with new problems and challenges posed by their continuously changing environment,” adds Carella. 

Problem Solving Best Practices

By nature, creative problem solving does not have a clear-cut set of do’s and don’ts. Rather, creating a culture of strong creative problem solvers requires flexibility, adaptation, and interpersonal skills. However, there are a several best practices that you should incorporate:

• Use a Systematic Approach: Regardless of the technique you use, choose a systematic method that satisfies your workplace conditions and constraints (time, resources, budget, etc.). Although you want to preserve creativity and openness to new ideas, maintaining a structured approach to the process will help you stay organized and focused. 
• View Problems as Opportunities: Rather than focusing on the negatives or giving up when you encounter barriers, treat problems as opportunities to enact positive change on the situation. In fact, some experts even recommend defining problems as opportunities, to remain proactive and positive.
• Change Perspective: Remember that there are multiple ways to solve any problem. If you feel stuck, changing perspective can help generate fresh ideas. A perspective change might entail seeking advice of a mentor or expert, understanding the context of a situation, or taking a break and returning to the problem later. “A sterile or familiar environment can stifle new thinking and new perspectives,” says Carella. “Make sure you get out to draw inspiration from spaces and people out of your usual reach.”
• Break Down Silos: To invite the greatest possible number of perspectives to any problem, encourage teams to work cross-departmentally. This not only combines diverse expertise, but also creates a more trusting and collaborative environment, which is essential to effective CPS. According to Carella, “Big challenges are always best tackled by a group of people rather than left to a single individual. Make sure you create a space where the team can concentrate and convene.”
• Employ Strong Leadership or a Facilitator: Some companies choose to hire an external facilitator that teaches problem solving techniques, best practices, and practicums to stimulate creative problem solving. But, internal managers and staff can also oversee these activities. Regardless of whether the facilitator is internal or external, choose a strong leader who will value others’ ideas and make space for creative solutions.  Mattimore has specific advice regarding the role of a facilitator: “When facilitating, get the group to name a promising idea (it will crystalize the idea and make it more memorable), and facilitate deeper rather than broader. Push for not only ideas, but how an idea might specifically work, some of its possible benefits, who and when would be interested in an idea, etc. This fleshing-out process with a group will generate fewer ideas, but at the end of the day will yield more useful concepts that might be profitably pursued.” Additionally, Carella says that “Executives and managers don’t necessarily have to be creative problem solvers, but need to make sure that their teams are equipped with the right tools and resources to make this happen. Also they need to be able to foster an environment where failing fast is accepted and celebrated.”
• Evaluate Your Current Processes: This practice can help you unlock bottlenecks, and also identify gaps in your data and information management, both of which are common roots of business problems.

MacLeod offers the following additional advice, “Always get the facts. Don’t jump too quickly to a solution – working through [problems] takes time and patience.”

Mattimore also stresses that how you introduce creative problem solving is important. “Do not start by introducing a new company-wide innovation process,” he says. “Instead, encourage smaller teams to pursue specific creative projects, and then build a process from the ground up by emulating these smaller teams’ successful approaches. We say: ‘You don’t innovate by changing the culture, you change the culture by innovating.’”

Barriers to Effective Problem Solving

Learning how to effectively solve problems is difficult and takes time and continual adaptation. There are several common barriers to successful CPS, including:

• Confirmation Bias: The tendency to only search for or interpret information that confirms a person’s existing ideas. People misinterpret or disregard data that doesn’t align with their beliefs.
• Mental Set: People’s inclination to solve problems using the same tactics they have used to solve problems in the past. While this can sometimes be a useful strategy (see Analogical Thinking in a later section), it often limits inventiveness and creativity.
• Functional Fixedness: This is another form of narrow thinking, where people become “stuck” thinking in a certain way and are unable to be flexible or change perspective.
• Unnecessary Constraints: When people are overwhelmed with a problem, they can invent and impose additional limits on solution avenues. To avoid doing this, maintain a structured, level-headed approach to evaluating causes, effects, and potential solutions.
• Groupthink: Be wary of the tendency for group members to agree with each other — this might be out of conflict avoidance, path of least resistance, or fear of speaking up. While this agreeableness might make meetings run smoothly, it can actually stunt creativity and idea generation, therefore limiting the success of your chosen solution.
• Irrelevant Information: The tendency to pile on multiple problems and factors that may not even be related to the challenge at hand. This can cloud the team’s ability to find direct, targeted solutions.
• Paradigm Blindness: This is found in people who are unwilling to adapt or change their worldview, outlook on a particular problem, or typical way of processing information. This can erode the effectiveness of problem solving techniques because they are not aware of the narrowness of their thinking, and therefore cannot think or act outside of their comfort zone.

According to Jaffa, the primary barrier of effective problem solving is rigidity. “The most common things people say are, ‘We’ve never done it before,’ or ‘We’ve always done it this way.’” While these feelings are natural, Jaffa explains that this rigid thinking actually precludes teams from identifying creative, inventive solutions that result in the greatest benefit.

“The biggest barrier to creative problem solving is a lack of awareness – and commitment to – training employees in state-of-the-art creative problem-solving techniques,” Mattimore explains. “We teach our clients how to use ideation techniques (as many as two-dozen different creative thinking techniques) to help them generate more and better ideas. Ideation techniques use specific and customized stimuli, or ‘thought triggers’ to inspire new thinking and new ideas.” 

MacLeod adds that ineffective or rushed leadership is another common culprit. “We're always in a rush to fix quickly,” she says. “Sometimes leaders just solve problems themselves, making unilateral decisions to save time. But the investment is well worth it — leaders will have less on their plates if they can teach and eventually trust the team to resolve. Teams feel empowered and engagement and investment increases.”

Strategies for Problem Cause Identification

As discussed, most experts agree that the first and most crucial step in problem solving is defining the problem. Once you’ve done this, however, it may not be appropriate to move straight to the solution phase. Rather, it is often helpful to identify the cause(s) of the problem: This will better inform your solution planning and execution, and help ensure that you don’t fall victim to the same challenges in the future. 

Below are some of the most common strategies for identifying the cause of a problem:

• Root Cause Analysis: This method helps identify the most critical cause of a problem. A factor is considered a root cause if removing it prevents the problem from recurring. Performing a root cause analysis is a 12 step process that includes: define the problem, gather data on the factors contributing to the problem, group the factors based on shared characteristics, and create a cause-and-effect timeline to determine the root cause. After that, you identify and evaluate corrective actions to eliminate the root cause.

‌ Download Fishbone Diagram Template - Excel

Download 5 Whys Template   Excel  |  Word  |  PDF   

Problem Solving Techniques and Strategies

In this section, we’ll explain several traditional and creative problem solving methods that you can use to identify challenges, create actionable goals, and resolve problems as they arise. Although there is often procedural and objective crossover among techniques, they are grouped by theme so you can identify which method works best for your organization.

Divergent Creative Problem Solving Techniques

Brainstorming: One of the most common methods of divergent thinking, brainstorming works best in an open group setting where everyone is encouraged to share their creative ideas. The goal is to generate as many ideas as possible – you analyze, critique, and evaluate the ideas only after the brainstorming session is complete. To learn more specific brainstorming techniques, read this article . 

Mind Mapping: This is a visual thinking tool where you graphically depict concepts and their relation to one another. You can use mind mapping to structure the information you have, analyze and synthesize it, and generate solutions and new ideas from there. The goal of a mind map is to simplify complicated problems so you can more clearly identify solutions.

Appreciative Inquiry (AI): The basic assumption of AI is that “an organization is a mystery to be embraced.” Using this principle, AI takes a positive, inquisitive approach to identifying the problem, analyzing the causes, and presenting possible solutions. The five principles of AI emphasize dialogue, deliberate language and outlook, and social bonding. 

Lateral Thinking: This is an indirect problem solving approach centered on the momentum of idea generation. As opposed to critical thinking, where people value ideas based on their truth and the absence of errors, lateral thinking values the “movement value” of new ideas: This means that you reward team members for producing a large volume of new ideas rapidly. With this approach, you’ll generate many new ideas before approving or rejecting any.

Problem Solving Techniques to Change Perspective

Constructive Controversy: This is a structured approach to group decision making to preserve critical thinking and disagreement while maintaining order. After defining the problem and presenting multiple courses of action, the group divides into small advocacy teams who research, analyze, and refute a particular option. Once each advocacy team has presented its best-case scenario, the group has a discussion (advocacy teams still defend their presented idea). Arguing and playing devil’s advocate is encouraged to reach an understanding of the pros and cons of each option. Next, advocacy teams abandon their cause and evaluate the options openly until they reach a consensus. All team members formally commit to the decision, regardless of whether they advocated for it at the beginning. You can learn more about the goals and steps in constructive controversy here . 

Carella is a fan of this approach. “Create constructive controversy by having two teams argue the pros and cons of a certain idea,” he says. “It forces unconscious biases to surface and gives space for new ideas to formulate.”

Abstraction: In this method, you apply the problem to a fictional model of the current situation. Mapping an issue to an abstract situation can shed extraneous or irrelevant factors, and reveal places where you are overlooking obvious solutions or becoming bogged down by circumstances. 

Analogical Thinking: Also called analogical reasoning , this method relies on an analogy: using information from one problem to solve another problem (these separate problems are called domains). It can be difficult for teams to create analogies among unrelated problems, but it is a strong technique to help you identify repeated issues, zoom out and change perspective, and prevent the problems from occurring in the future. .

CATWOE: This framework ensures that you evaluate the perspectives of those whom your decision will impact. The factors and questions to consider include (which combine to make the acronym CATWOE):

• Customers: Who is on the receiving end of your decisions? What problem do they currently have, and how will they react to your proposed solution?
• Actors: Who is acting to bring your solution to fruition? How will they respond and be affected by your decision?
• Transformation Process: What processes will you employ to transform your current situation and meet your goals? What are the inputs and outputs?
• World View: What is the larger context of your proposed solution? What is the larger, big-picture problem you are addressing?
• Owner: Who actually owns the process? How might they influence your proposed solution (positively or negatively), and how can you influence them to help you?
• Environmental Constraints: What are the limits (environmental, resource- and budget-wise, ethical, legal, etc.) on your ideas? How will you revise or work around these constraints?

Complex Problem Solving

Soft Systems Methodology (SSM): For extremely complex problems, SSM can help you identify how factors interact, and determine the best course of action. SSM was borne out of organizational process modeling and general systems theory, which hold that everything is part of a greater, interconnected system: This idea works well for “hard” problems (where logic and a single correct answer are prioritized), and less so for “soft” problems (i.e., human problems where factors such as personality, emotions, and hierarchy come into play). Therefore, SSM defines a seven step process for problem solving: 

• Begin with the problem or problematic situation 
• Express the problem or situation and build a rich picture of the themes of the problem 
• Identify the root causes of the problem (most commonly with CATWOE)
• Build conceptual models of human activity surrounding the problem or situation
• Compare models with real-world happenings
• Identify changes to the situation that are both feasible and desirable
• Take action to implement changes and improve the problematic situation

SSM can be used for any complex soft problem, and is also a useful tool in change management . 

Failure Mode and Effects Analysis (FMEA): This method helps teams anticipate potential problems and take steps to mitigate them. Use FMEA when you are designing (redesigning) a complex function, process, product, or service. First, identify the failure modes, which are the possible ways that a project could fail. Then, perform an effects analysis to understand the consequences of each of the potential downfalls. This exercise is useful for internalizing the severity of each potential failure and its effects so you can make adjustments or safeties in your plan. 

‌ Download FMEA Template  

Problem Solving Based on Data or Logic (Heuristic Methods)

TRIZ: A Russian-developed problem solving technique that values logic, analysis, and forecasting over intuition or soft reasoning. TRIZ (translated to “theory of inventive problem solving” or TIPS in English) is a systematic approach to defining and identifying an inventive solution to difficult problems. The method offers several strategies for arriving at an inventive solution, including a contradictions matrix to assess trade-offs among solutions, a Su-Field analysis which uses formulas to describe a system by its structure, and ARIZ (algorithm of inventive problem solving) which uses algorithms to find inventive solutions. 

Inductive Reasoning: A logical method that uses evidence to conclude that a certain answer is probable (this is opposed to deductive reasoning, where the answer is assumed to be true). Inductive reasoning uses a limited number of observations to make useful, logical conclusions (for example, the Scientific Method is an extreme example of inductive reasoning). However, this method doesn’t always map well to human problems in the workplace — in these instances, managers should employ intuitive inductive reasoning , which allows for more automatic, implicit conclusions so that work can progress. This, of course, retains the principle that these intuitive conclusions are not necessarily the one and only correct answer. 

Process-Oriented Problem Solving Methods

Plan Do Check Act (PDCA): This is an iterative management technique used to ensure continual improvement of products or processes. First, teams plan (establish objectives to meet desired end results), then do (implement the plan, new processes, or produce the output), then check (compare expected with actual results), and finally act (define how the organization will act in the future, based on the performance and knowledge gained in the previous three steps). 

Means-End Analysis (MEA): The MEA strategy is to reduce the difference between the current (problematic) state and the goal state. To do so, teams compile information on the multiple factors that contribute to the disparity between the current and goal states. Then they try to change or eliminate the factors one by one, beginning with the factor responsible for the greatest difference in current and goal state. By systematically tackling the multiple factors that cause disparity between the problem and desired outcome, teams can better focus energy and control each step of the process. 

Hurson’s Productive Thinking Model: This technique was developed by Tim Hurson, and is detailed in his 2007 book Think Better: An Innovator’s Guide to Productive Thinking . The model outlines six steps that are meant to give structure while maintaining creativity and critical thinking: 1) Ask “What is going on?” 2) Ask “What is success?” 3) Ask “What is the question?” 4) Generate answers 5) Forge the solution 6) Align resources. 

Control Influence Accept (CIA): The basic premise of CIA is that how you respond to problems determines how successful you will be in overcoming them. Therefore, this model is both a problem solving technique and stress-management tool that ensures you aren’t responding to problems in a reactive and unproductive way. The steps in CIA include:

• Control: Identify the aspects of the problem that are within your control.
• Influence: Identify the aspects of the problem that you cannot control, but that you can influence.
• Accept: Identify the aspects of the problem that you can neither control nor influence, and react based on this composite information. 

GROW Model: This is a straightforward problem solving method for goal setting that clearly defines your goals and current situation, and then asks you to define the potential solutions and be realistic about your chosen course of action. The steps break down as follows:

• Goal: What do you want?
• Reality: Where are you now?
• Options: What could you do?
• Will: What will you do?

OODA Loop: This acronym stands for observe, orient, decide, and act. This approach is a decision-making cycle that values agility and flexibility over raw human force. It is framed as a loop because of the understanding that any team will continually encounter problems or opponents to success and have to overcome them.

There are also many un-named creative problem solving techniques that follow a sequenced series of steps. While the exact steps vary slightly, they all follow a similar trajectory and aim to accomplish similar goals of problem, cause, and goal identification, idea generation, and active solution implementation.

MacLeod offers her own problem solving procedure, which echoes the above steps:

“1. Recognize the Problem: State what you see. Sometimes the problem is covert. 2. Identify: Get the facts — What exactly happened? What is the issue? 3. and 4. Explore and Connect: Dig deeper and encourage group members to relate their similar experiences. Now you're getting more into the feelings and background [of the situation], not just the facts.  5. Possible Solutions: Consider and brainstorm ideas for resolution. 6. Implement: Choose a solution and try it out — this could be role play and/or a discussion of how the solution would be put in place.  7. Evaluate: Revisit to see if the solution was successful or not.”

Many of these problem solving techniques can be used in concert with one another, or multiple can be appropriate for any given problem. It’s less about facilitating a perfect CPS session, and more about encouraging team members to continually think outside the box and push beyond personal boundaries that inhibit their innovative thinking. So, try out several methods, find those that resonate best with your team, and continue adopting new techniques and adapting your processes along the way. 

Improve Problem Solving with Work Management in Smartsheet

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time.  Try Smartsheet for free, today.

Discover why over 90% of Fortune 100 companies trust Smartsheet to get work done.

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

A guide to problem-solving techniques, steps, and skills

You might associate problem-solving with the math exercises that a seven-year-old would do at school. But problem-solving isn’t just about math — it’s a crucial skill that helps everyone make better decisions in everyday life or work.

Problem-solving involves finding effective solutions to address complex challenges, in any context they may arise.

Unfortunately, structured and systematic problem-solving methods aren’t commonly taught. Instead, when solving a problem, PMs tend to rely heavily on intuition. While for simple issues this might work well, solving a complex problem with a straightforward solution is often ineffective and can even create more problems.

In this article, you’ll learn a framework for approaching problem-solving, alongside how you can improve your problem-solving skills.

The 7 steps to problem-solving

When it comes to problem-solving there are seven key steps that you should follow: define the problem, disaggregate, prioritize problem branches, create an analysis plan, conduct analysis, synthesis, and communication.

1. Define the problem

Problem-solving begins with a clear understanding of the issue at hand. Without a well-defined problem statement, confusion and misunderstandings can hinder progress. It’s crucial to ensure that the problem statement is outcome-focused, specific, measurable whenever possible, and time-bound.

Additionally, aligning the problem definition with relevant stakeholders and decision-makers is essential to ensure efforts are directed towards addressing the actual problem rather than side issues.

2. Disaggregate

Complex issues often require deeper analysis. Instead of tackling the entire problem at once, the next step is to break it down into smaller, more manageable components.

Various types of logic trees (also known as issue trees or decision trees) can be used to break down the problem. At each stage where new branches are created, it’s important for them to be “MECE” – mutually exclusive and collectively exhaustive. This process of breaking down continues until manageable components are identified, allowing for individual examination.

The decomposition of the problem demands looking at the problem from various perspectives. That is why collaboration within a team often yields more valuable results, as diverse viewpoints lead to a richer pool of ideas and solutions.

3. Prioritize problem branches

The next step involves prioritization. Not all branches of the problem tree have the same impact, so it’s important to understand the significance of each and focus attention on the most impactful areas. Prioritizing helps streamline efforts and minimize the time required to solve the problem.

Over 200k developers and product managers use LogRocket to create better digital experiences

4. Create an analysis plan

For prioritized components, you may need to conduct in-depth analysis. Before proceeding, a work plan is created for data gathering and analysis. If work is conducted within a team, having a plan provides guidance on what needs to be achieved, who is responsible for which tasks, and the timelines involved.

5. Conduct analysis

Data gathering and analysis are central to the problem-solving process. It’s a good practice to set time limits for this phase to prevent excessive time spent on perfecting details. You can employ heuristics and rule-of-thumb reasoning to improve efficiency and direct efforts towards the most impactful work.

6. Synthesis

After each individual branch component has been researched, the problem isn’t solved yet. The next step is synthesizing the data logically to address the initial question. The synthesis process and the logical relationship between the individual branch results depend on the logic tree used.

7. Communication

The last step is communicating the story and the solution of the problem to the stakeholders and decision-makers. Clear effective communication is necessary to build trust in the solution and facilitates understanding among all parties involved. It ensures that stakeholders grasp the intricacies of the problem and the proposed solution, leading to informed decision-making.

Exploring problem-solving in various contexts

While problem-solving has traditionally been associated with fields like engineering and science, today it has become a fundamental skill for individuals across all professions. In fact, problem-solving consistently ranks as one of the top skills required by employers.

Problem-solving techniques can be applied in diverse contexts:

• Individuals — What career path should I choose? Where should I live? These are examples of simple and common personal challenges that require effective problem-solving skills
• Organizations — Businesses also face many decisions that are not trivial to answer. Should we expand into new markets this year? How can we enhance the quality of our product development? Will our office accommodate the upcoming year’s growth in terms of capacity?
• Societal issues — The biggest world challenges are also complex problems that can be addressed with the same technique. How can we minimize the impact of climate change? How do we fight cancer?

Despite the variation in domains and contexts, the fundamental approach to solving these questions remains the same. It starts with gaining a clear understanding of the problem, followed by decomposition, conducting analysis of the decomposed branches, and synthesizing it into a result that answers the initial problem.

Real-world examples of problem-solving

Let’s now explore some examples where we can apply the problem solving framework.

Problem: In the production of electronic devices, you observe an increasing number of defects. How can you reduce the error rate and improve the quality?

Before delving into analysis, you can deprioritize branches that you already have information for or ones you deem less important. For instance, while transportation delays may occur, the resulting material degradation is likely negligible. For other branches, additional research and data gathering may be necessary.

Once results are obtained, synthesis is crucial to address the core question: How can you decrease the defect rate?

While all factors listed may play a role, their significance varies. Your task is to prioritize effectively. Through data analysis, you may discover that altering the equipment would bring the most substantial positive outcome. However, executing a solution isn’t always straightforward. In prioritizing, you should consider both the potential impact and the level of effort needed for implementation.

By evaluating impact and effort, you can systematically prioritize areas for improvement, focusing on those with high impact and requiring minimal effort to address. This approach ensures efficient allocation of resources towards improvements that offer the greatest return on investment.

Problem : What should be my next job role?

When breaking down this problem, you need to consider various factors that are important for your future happiness in the role. This includes aspects like the company culture, our interest in the work itself, and the lifestyle that you can afford with the role.

However, not all factors carry the same weight for us. To make sense of the results, we can assign a weight factor to each branch. For instance, passion for the job role may have a weight factor of 1, while interest in the industry may have a weight factor of 0.5, because that is less important for you.

By applying these weights to a specific role and summing the values, you can have an estimate of how suitable that role is for you. Moreover, you can compare two roles and make an informed decision based on these weighted indicators.

Key problem-solving skills

This framework provides the foundation and guidance needed to effectively solve problems. However, successfully applying this framework requires the following:

• Creativity — During the decomposition phase, it’s essential to approach the problem from various perspectives and think outside the box to generate innovative ideas for breaking down the problem tree
• Decision-making — Throughout the process, decisions must be made, even when full confidence is lacking. Employing rules of thumb to simplify analysis or selecting one tree cut over another requires decisiveness and comfort with choices made
• Analytical skills — Analytical and research skills are necessary for the phase following decomposition, involving data gathering and analysis on selected tree branches
• Teamwork — Collaboration and teamwork are crucial when working within a team setting. Solving problems effectively often requires collective effort and shared responsibility
• Communication — Clear and structured communication is essential to convey the problem solution to stakeholders and decision-makers and build trust

How to enhance your problem-solving skills

Problem-solving requires practice and a certain mindset. The more you practice, the easier it becomes. Here are some strategies to enhance your skills:

• Practice structured thinking in your daily life — Break down problems or questions into manageable parts. You don’t need to go through the entire problem-solving process and conduct detailed analysis. When conveying a message, simplify the conversation by breaking the message into smaller, more understandable segments
• Regularly challenging yourself with games and puzzles — Solving puzzles, riddles, or strategy games can boost your problem-solving skills and cognitive agility.
• Engage with individuals from diverse backgrounds and viewpoints — Conversing with people who offer different perspectives provides fresh insights and alternative solutions to problems. This boosts creativity and helps in approaching challenges from new angles

Final thoughts

Problem-solving extends far beyond mathematics or scientific fields; it’s a critical skill for making informed decisions in every area of life and work. The seven-step framework presented here provides a systematic approach to problem-solving, relevant across various domains.

Now, consider this: What’s one question currently on your mind? Grab a piece of paper and try to apply the problem-solving framework. You might uncover fresh insights you hadn’t considered before.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #career development
• #tools and resources

Stop guessing about your digital experience with LogRocket

Recent posts:.

Exploring augmented products: Beyond the core offering

Augmented products leverage technology and additional services to provide enhanced functionality, convenience, and value to users.

A guide to acceptance test-driven development (ATDD)

ATDD is an agile methodology involving collaboration to define acceptance criteria before starting any development.

Leader Spotlight: Empowering teams via a shared vision, with Brian Peterson

Brian Peterson discusses how he creates empowered teams by establishing a shared vision across teams, organizations, and the company.

Implementing pilot projects: Purpose, process, and best practices

Instead of making an entire upfront investment, the pilot project aims to test something on a reduced scale to assess whether it works.

Leave a Reply Cancel reply

What Is Problem Solving? How Software Engineers Approach Complex Challenges

From debugging an existing system to designing an entirely new software application, a day in the life of a software engineer is filled with various challenges and complexities. The one skill that glues these disparate tasks together and makes them manageable? Problem solving . 

Throughout this blog post, we’ll explore why problem-solving skills are so critical for software engineers, delve into the techniques they use to address complex challenges, and discuss how hiring managers can identify these skills during the hiring process. 

What Is Problem Solving?

But what exactly is problem solving in the context of software engineering? How does it work, and why is it so important?

Problem solving, in the simplest terms, is the process of identifying a problem, analyzing it, and finding the most effective solution to overcome it. For software engineers, this process is deeply embedded in their daily workflow. It could be something as simple as figuring out why a piece of code isn’t working as expected, or something as complex as designing the architecture for a new software system. 

In a world where technology is evolving at a blistering pace, the complexity and volume of problems that software engineers face are also growing. As such, the ability to tackle these issues head-on and find innovative solutions is not only a handy skill — it’s a necessity. 

The Importance of Problem-Solving Skills for Software Engineers

Problem-solving isn’t just another ability that software engineers pull out of their toolkits when they encounter a bug or a system failure. It’s a constant, ongoing process that’s intrinsic to every aspect of their work. Let’s break down why this skill is so critical.

Driving Development Forward

Without problem solving, software development would hit a standstill. Every new feature, every optimization, and every bug fix is a problem that needs solving. Whether it’s a performance issue that needs diagnosing or a user interface that needs improving, the capacity to tackle and solve these problems is what keeps the wheels of development turning.

It’s estimated that 60% of software development lifecycle costs are related to maintenance tasks, including debugging and problem solving. This highlights how pivotal this skill is to the everyday functioning and advancement of software systems.

Innovation and Optimization

The importance of problem solving isn’t confined to reactive scenarios; it also plays a major role in proactive, innovative initiatives . Software engineers often need to think outside the box to come up with creative solutions, whether it’s optimizing an algorithm to run faster or designing a new feature to meet customer needs. These are all forms of problem solving.

Consider the development of the modern smartphone. It wasn’t born out of a pre-existing issue but was a solution to a problem people didn’t realize they had — a device that combined communication, entertainment, and productivity into one handheld tool.

Increasing Efficiency and Productivity

Good problem-solving skills can save a lot of time and resources. Effective problem-solvers are adept at dissecting an issue to understand its root cause, thus reducing the time spent on trial and error. This efficiency means projects move faster, releases happen sooner, and businesses stay ahead of their competition.

Improving Software Quality

Problem solving also plays a significant role in enhancing the quality of the end product. By tackling the root causes of bugs and system failures, software engineers can deliver reliable, high-performing software. This is critical because, according to the Consortium for Information and Software Quality, poor quality software in the U.S. in 2022 cost at least $2.41 trillion in operational issues, wasted developer time, and other related problems.

Problem-Solving Techniques in Software Engineering

So how do software engineers go about tackling these complex challenges? Let’s explore some of the key problem-solving techniques, theories, and processes they commonly use.

Decomposition

Breaking down a problem into smaller, manageable parts is one of the first steps in the problem-solving process. It’s like dealing with a complicated puzzle. You don’t try to solve it all at once. Instead, you separate the pieces, group them based on similarities, and then start working on the smaller sets. This method allows software engineers to handle complex issues without being overwhelmed and makes it easier to identify where things might be going wrong.

Abstraction

In the realm of software engineering, abstraction means focusing on the necessary information only and ignoring irrelevant details. It is a way of simplifying complex systems to make them easier to understand and manage. For instance, a software engineer might ignore the details of how a database works to focus on the information it holds and how to retrieve or modify that information.

Algorithmic Thinking

At its core, software engineering is about creating algorithms — step-by-step procedures to solve a problem or accomplish a goal. Algorithmic thinking involves conceiving and expressing these procedures clearly and accurately and viewing every problem through an algorithmic lens. A well-designed algorithm not only solves the problem at hand but also does so efficiently, saving computational resources.

Parallel Thinking

Parallel thinking is a structured process where team members think in the same direction at the same time, allowing for more organized discussion and collaboration. It’s an approach popularized by Edward de Bono with the “ Six Thinking Hats ” technique, where each “hat” represents a different style of thinking.

In the context of software engineering, parallel thinking can be highly effective for problem solving. For instance, when dealing with a complex issue, the team can use the “White Hat” to focus solely on the data and facts about the problem, then the “Black Hat” to consider potential problems with a proposed solution, and so on. This structured approach can lead to more comprehensive analysis and more effective solutions, and it ensures that everyone’s perspectives are considered.

This is the process of identifying and fixing errors in code . Debugging involves carefully reviewing the code, reproducing and analyzing the error, and then making necessary modifications to rectify the problem. It’s a key part of maintaining and improving software quality.

Testing and Validation

Testing is an essential part of problem solving in software engineering. Engineers use a variety of tests to verify that their code works as expected and to uncover any potential issues. These range from unit tests that check individual components of the code to integration tests that ensure the pieces work well together. Validation, on the other hand, ensures that the solution not only works but also fulfills the intended requirements and objectives.

Explore verified tech roles & skills.

The definitive directory of tech roles, backed by machine learning and skills intelligence.

Explore all roles

Evaluating Problem-Solving Skills

We’ve examined the importance of problem-solving in the work of a software engineer and explored various techniques software engineers employ to approach complex challenges. Now, let’s delve into how hiring teams can identify and evaluate problem-solving skills during the hiring process.

Recognizing Problem-Solving Skills in Candidates

How can you tell if a candidate is a good problem solver? Look for these indicators:

• Previous Experience: A history of dealing with complex, challenging projects is often a good sign. Ask the candidate to discuss a difficult problem they faced in a previous role and how they solved it.
• Problem-Solving Questions: During interviews, pose hypothetical scenarios or present real problems your company has faced. Ask candidates to explain how they would tackle these issues. You’re not just looking for a correct solution but the thought process that led them there.
• Technical Tests: Coding challenges and other technical tests can provide insight into a candidate’s problem-solving abilities. Consider leveraging a platform for assessing these skills in a realistic, job-related context.

Assessing Problem-Solving Skills

Once you’ve identified potential problem solvers, here are a few ways you can assess their skills:

• Solution Effectiveness: Did the candidate solve the problem? How efficient and effective is their solution?
• Approach and Process: Go beyond whether or not they solved the problem and examine how they arrived at their solution. Did they break the problem down into manageable parts? Did they consider different perspectives and possibilities?
• Communication: A good problem solver can explain their thought process clearly. Can the candidate effectively communicate how they arrived at their solution and why they chose it?
• Adaptability: Problem-solving often involves a degree of trial and error. How does the candidate handle roadblocks? Do they adapt their approach based on new information or feedback?

Hiring managers play a crucial role in identifying and fostering problem-solving skills within their teams. By focusing on these abilities during the hiring process, companies can build teams that are more capable, innovative, and resilient.

Key Takeaways

As you can see, problem solving plays a pivotal role in software engineering. Far from being an occasional requirement, it is the lifeblood that drives development forward, catalyzes innovation, and delivers of quality software. 

By leveraging problem-solving techniques, software engineers employ a powerful suite of strategies to overcome complex challenges. But mastering these techniques isn’t simple feat. It requires a learning mindset, regular practice, collaboration, reflective thinking, resilience, and a commitment to staying updated with industry trends. 

For hiring managers and team leads, recognizing these skills and fostering a culture that values and nurtures problem solving is key. It’s this emphasis on problem solving that can differentiate an average team from a high-performing one and an ordinary product from an industry-leading one.

At the end of the day, software engineering is fundamentally about solving problems — problems that matter to businesses, to users, and to the wider society. And it’s the proficient problem solvers who stand at the forefront of this dynamic field, turning challenges into opportunities, and ideas into reality.

This article was written with the help of AI. Can you tell which parts?

Get started with HackerRank

Over 2,500 companies and 40% of developers worldwide use HackerRank to hire tech talent and sharpen their skills.

Recommended topics

• Hire Developers
• Problem Solving

Does a College Degree Still Matter for Developers in 2024?

The Community

Modern analyst blog, community blog.

• Member Profiles

Networking Opportunities

Community spotlight, business analysis glossary, articles listing, business analyst humor, self assessment.

• Training Courses
• Organizations
• Resume Writing Tips
• Interview Questions

Let Us Help Your Business

Advertise with us, rss feeds & syndication, privacy policy.

A New Information Systems Paradigm: What does a Business Analyst Needs to Know?

Introduction

A paradigm shift is a subtle but important change from one way of thinking to another. It's a revolution, a transformation, a sort of metamorphosis. It doesn’t just happen, but rather a strong impetus for change drives it. The two major areas for change driving the new IS shift are the desire or need to:

(1) manage business process and business rules as separate but closely related and connected resources and

(2) decompose software or programming code into reusable modules, called services, managed by a service oriented architecture (SOA) infrastructure. The SOA infrastructure manages and mediates services used in a business process.

Research and practice proves that a successful paradigm shift cannot happen without training and educating those in the middle of it. Lack of training and education is currently impeding the current IS paradigm shift. There is a shortage in today’s enterprises of people trained in business process, rules management, and SOA. Part of the reason for this educational deficit, is that IS academic programs are slow to respond to the serious changes occurring in most industries today.

This article has three outcomes. The first is to provide an overview of the new breed of information systems including what a business analyst needs to know and what acorresponding academic or training curriculum needs to include. The second outcome is to demonstrate how one undergraduate IS academic program has addressed the major changes driving this paradigm shift. The third outcome is to provide references for readers interested in getting thetraining and skills to be successful in the new IS paradigm.

Early Information Systems

Early information systems were developed as one complete programming entity that included the business process, business logic, and data management functions mixed together. In the 1960s, database management systems appeared that managed data as a resource separate from the process and logic. Managing data separately created a number of amazing benefits. The major ones are: shared and easier access to data, more system adaptability due to data independence, and better data integrity. One critical benefit often overlooked is that database management systems deliver direct access to data, through easy-to-use query languages, to business users.

However, the navigational database management systems of the 1960s were not very effective because they were designed for use primarily by IT professionals and not by business folks. Thus, the separation of data alone did not deliver on the total promise of effective data management. Total effective data management became possible only with the adoption of the relational data model in the 1970s. The relational data model is technology-independent which means it is independent of how and where it is executed and whether automated or not. It created a new level of conceptualization that allowed the business folks, not just IT professionals, to understand, use and manage data. That is when the paradigm shift in the data world became real.

Thus, starting in the 1970s, information systems were developed with a database-driven focus illustrated in Figure 1. The data component of the system was developed and implemented using a relational database management system. The application or business logic was programmed in the COBOL programming language. Today the most common programming languages are Java and C++.

Figure 1: Database-Driven Information Systems

A Typical Undergraduate Information Systems Academic Program Prior to the New Paradigm

The Management Information Systems (MIS) program in the Terry School of Business at the University of Georgia (UGA) is a representative framework of a typical IS academic program. The MIS major at the University of Georgia builds on the Terry College of Business common business core, which includes course work in accounting, economics, business law, mathematics, statistics, information systems, finance, marketing, production, and management. Often students complete the common core before taking course work in the MIS program.

The UGA MIS program equips students with the tools for "leading IT-enabled change in organizations." MIS students typically find careers as consultants or business analysts. The Terry MIS program provides the foundation for students to go in a technical direction (such as a programmer or database administrator), a non-technical direction (such as a business analyst or project manager), or somewhere in the middle (such as a business intelligence or IT risk and security specialist).

The MIS Department has 11 full-time and 3 part-time faculty members. There are 250 undergraduate MIS majors and 60 students in the Masters of Internet program. MIS courses are also taught in the full-time and part-time MBA programs. In addition, the Department has six PhD students. MIS students have some of the highest placement, internship, starting salaries, and job satisfaction rates of any major in the Terry College. The Terry MIS program is ranked among the top 15 in the U.S., and the faculty is world-renowned. MIS is a hands-on major which equips students with real-world skills that are in demand in the job market.

As with any IS academic program developed in the last 40 years, the UGA MIS program has focused on the design, development and implementation of the database-driven information systems shown in Figure 1. This database-driven focus is reflected in UGA MIS curriculum up until 2008 (see Figure 2). Note there are four required courses and three required electives. In the Terry College of Business, majors are limited to seven courses. The two required programming courses deal with the development, testing, and implementation of business logic in the information system. While the database course deals with the data management aspects of the information system, the remaining required course deals with the overall perspective of business analysis and systems development. The two bolded electives in Figure 2, business process management and project management, were implemented as electivesin 2007 when the MIS Department recognized that major changes were taking place in the field requiring an innovative response.

The Changing Paradigm: the New Breed of Information Systems

As mentioned above, two major areas for change that are driving a new breed of information systems are the desire or need to:

(1) manage business process and business rules as separate resources but are closely connected; and (2) decompose software or programming code into reusable modules, call services, and managed by a service oriented architecture (SOA) infrastructure.

These changes are creating Process-Based Information System depicted in Figure 3. Similar to what happen with data 50 years ago, the business process is separated and managed by a Business Process Management System (BPMS) and the business rules (business logic), are separated and managed by a Business Rules/Decision Management System (BRMS/BDMS). Within this new type of system, the application is the business process actually executed by the BPMS, as shown in Figure 3. During execution, the different services assigned to activities in the business processare executed and may be a task (application logic), rule/decision and/or database service. The SOA infrastructure manages and mediates services used in the business process.

BPMS and SOA

A BPMS is a platform for developing, running and managing business process oriented information systems. On one hand, it is a development platform for creating information systems without programming. The BPMS provides a software environment that allows the user (e.g., business analyst) to model and improve business processes. Many refer to the systems created by BPMS as composite or process-based applications/systems because the user is composing the application instead of building or buying it. The user composes the application or system by selecting existing services and assigning them to activities within the business process which is then executed by the BPMS. The analogy for this would be using Lego blocks to create a toy structure. Lego bricks can be assembled and connected in many ways, to construct such objects as vehicles, buildings, and even working robots. Anything constructed can then be taken apart again, and the pieces used to make other objects. Thus, a BPMS is a platform for developing process-based systems and a platform for executing these systems in real-time and monitor the results.

The key to business process management, whether taking a business management or technical perspective, is the development of a good process model. A process model (e.g.,order process) captures the sequences of activities (get customer information, determine order and discount amounts, compute taxes, etc.) from the initiating event of a process (customer order is entered) to a defined end state (success [order shipped] or exception [order denied due to bad credit]). The process model is a map of all possible paths from the initiating event to all possible end states. It is not just a diagram; its purpose is to convey meaning. From the diagram alone, the process logic should be clear enough and understandable to a business person to be useful for managing the business process while also being semantically precise enough, as required by technical personnel (business analyst developing requirements for a system) or a software system (BPMS) from which to develop and execute the application/system.

For years many different flowcharting representations captured business processes. However, resulting flowcharting diagrams were not sufficient for capturing the complexity of a business process to be easily understood by business folks and yet precise enough to describe technical details for process execution in a BPMS (Silver, 2011). An example of the limited capabilities of the flowchart model is its inability to model event-triggered behavior such as a customer canceling an order. Such event-triggered behavior happens all the time but is not easily modeled in a flowchart. As with early database management systems, these flowcharting systems weremainly an IT tool, not intended for business people. Thus, for the new IS paradigm to become real, a new more powerful process modeling language was needed.

The answer came with BPMN, Business Process Model and Notation. BPMN is a graphical powerful diagramming language for business process flows. The most important benefit of BPMN is that it is a standard, maintained by the Object Management Group (http://www.bpmn.org/) . This means that the language is not owned or controlled by a single company, but rather that it is managed by a group of representatives from different interested companies including software vendors and consulting companies. The first approved specification, BPMN 1.0, was adopted in February 2006. Since then, there has been BPMN 1.1, 1.2 and the latest specification BPMN 2.0, proposed in January 2011. Today, virtually every process modeling software tool supports BPMN in some fashion although only a few have implemented BPMN 2.0. For those readers wanting to learn more about BPMN see Silver (2011).

A key benefit of a process modeling standard is that process models can be shared between software tools, and thus, users of different tools can understand models created in a tool that they are not currently using. The semantics and the notation are defined by the standard, not by each tool. BPMN is a rich language, able to describe the complexities of a business process compactly in a diagram. BPMN is also able to describe process meaning in enough technical details to enable process execution in a BPMS. Thus, BPMN provides a bridge between the worlds of business and IT through the use of a common process language that can be used to develop shared models used by both groups.

As stated earlier, in the new IS paradigm, a designer/analyst composes the application or system by selecting existing services and assigning them to activities within the business process which is then executed by the BPMS. This is where SOA (Service-Oriented Architecture) and BPMS work together. SOA is a set of architectural principles that leverages open standards to represent software applications as services. The fundamental principle is that each software application in the system is a service. Thus, individual software assets, services, become building blocks that can be reused in developing applications. The preferred method of implementing a SOA is Web services. The preferred way of deploying SOA is an Enterprise Service Bus.

The relationship between a BPMS and the SOA infrastructure is capture in Figure 4. One of the principles of BPMS design is to expose the BPMN process logic in a layer separate from the services used in the execution of that process. The BPMS manages the process-related activities while the SOA infrastructure manages and mediates the services used in the business process.

The service model provides the fundamental building block for developing systems in the new IS paradigm as shown in Figure 3. Each service is treated as a black box (encapsulated) by the BPMS. To use a service, the analyst/composer only needs to know the inputs and outputs for the service and how to access or trigger the service (usually a URL). For example, the first of the three activities displayed in Figure 4, which is part of larger order fulfillment process, might be to access the customer database to retrieve customer information. To implement this activity, an analyst enters into the BPMS the URL for the database service specifying inputs (customer number) and outputs (desired customer information) for that service. Composite design is implemented, simply by selecting the services and specifying location (URL), inputs and outputs. When the BPMS executes this process activity, the URL will be used to locate the service and then the SOA infrastructure will manage and mediate the execution of that service. Besides being treated as a black box, a service is platform and location independent. Location independent means that the service can exist anywhere on the Internet. Platform-independent means that the software service can be developed in any programming language. Since any software asset can be set up as a service or to act like a service, in the new IS paradigm all available software assets can be utilized as building blocks in the development and execution of process-based information systems.

Business Rules and the Decision Model

In Figure 3, the new breed of system has the option to separate business logic/rules and manage them separately using a Business Rules/Business Decision Management System (BRMS/BDMS). The focus is on separating business rules that are shared among systems, ones that are likely to change, or ones that are important for business people to see and know. In general, this is any business logic that business folks would like to manage in the system, but over which they want to retain business governance. The rules are created in a representative structure or language of the BRMS/BDMS and stored in a rule repository. Rules are invoked by a software application (BPMS) and executed by a business rules engine/server component of the BRMS/BDMS. These systems also provide tools for testing and simulating business rules and making rules available for run time adjustment by business users.

Using BRMS/BDMS provides a number of benefits: system agility (making changes quickly), better business-IT alignment, compliance, efficiency, continuous improvement, consistent decision-making and knowledge retention. These benefits all support the most important motivation for separating out business logic which is to enable business leaders to manage business logic for the good of the business. The separation of the business process discussed in the previous section also provides similar benefits and motivation for the management and execution of a business process.

BRMS have been around since the 1990s. Yet, they are not in widespread use, and thus, the separation of business rules has really not been very successful. One might wonder why this is the case given the many benefits of separation? To answer this, review the earlier discussions on the relational data model and BPMN process model. In both cases, separation alone did not deliver on the promise of effective data or process management. Effectiveness in these areas (and hence, new paradigms) became possible only with the adoption of the relational and BPMN models. BRMSs were primarily developed for and used by IT people and their primary level of modeling is at the individual rules and rule group level. This level of modeling is at the wrong level of abstraction and specificity for business (and business analyst) audiences.

It is clearly useful to separate business logic but to do it effectively a new level of abstraction, a new model, for managing business rules/logic is needed. Based on the experience with data and process models, this new model needs to be technology-independent and have the ability to bridge the business and IT communities. von Halle and Goldberg published a book in 2009 outlining in depth the type of model needed, referred to as the Decision Model. It defines a technology-independent way of organizing and modeling business logic in terms of decisions and sets of business rules (rule families) that go into making a decision. It has a graphical notation for providing a high-level view of the decision and the relationships among rule families that make up the decision. This Decision Model is a pure representation of business logic independent of biases from process, data or technology. For more information on the decision model, see von Halle and Goldberg book (2010) and the tutorial article and other resources at the KPI website .

Despite being independent of technology, the Decision Model is easily implementable in technology, applicable to both current and future technology products. Decision Model concepts have already found their way into the rule management, RuleGuide ( http://www.newwisdomsoftware.com ), and BDMS software, OpenRules ( http://openrules.com/ ). A full decision modeling and execution BDMS, based on the Decision Model, was released in late 2011, Sapiens Decision ( http://www.sapiensdecision.com/ ).

The strength of the Decision Model is reflected in the speed of its implementation into technology, the rapid growth of successful applications of it in a number of cases . At the same time, the OMG has initiated a subcommittee called DMN (decision model notation) Group .

Before giving a brief example of how a BDMS (Business Decision Management System) works, it is helpful to understand how business rules and business process relate. Historically, business rules or parts of them were treated as pieces of the business process and embedded in the process model itself. This very common practice leads to complex business processes that are difficult to understand and manage and to business rules and logic that become impossible to maintain. Thus, it is critical in process modeling to identify those process tasks that make a decision and treat this decision as separate activity, not part of the business process. The business logic behind each such decision is modeled separately using the Decision Model.

For a brief example of how the Decision Model relates to a business process, revisit the three activities within a larger customer order fulfillment process illustrated in Figure 4. Assume the third activity denotes a decision task to determine discount amount. (Note that the business analyst was a good process modeler and separated out the decision into a separate activity.) The business analyst then develops a decision model for determining the discount amount decision. The analyst discovers that the decision is based on a set of rules or logic containing conditions about discount rate and order amount. The discount rate is determined by a set of rules that contain conditions involving customer classification and order amount (sample rule: If customer classification is “Gold” and order amount is between 500-2001 then the discount rate is .07). Customer classification is determined by a set of rules that contain conditions involving credit score and amount spent YTD.

A decision model represents these three sets of rules rule families represented in a graphical model showing the relationships among them. Developing, validating the integrity, and testing a complete decision model occurs in a BDMS such as Sapiens DECISION. Once the model is tested and deemed ready to use, the BDMS (depending on target automation technology) creates the code behind the decision service that would take order amount, credit score and amount spent YTD as inputs and deliver discount amount as an output. A URL is created for accessing the service. The decision service could then be used by the order fulfillment process (or any other process) by simply specifying the URL, inputs and output for this service when the BPMS activity is designed. When activity three is executed in the example process, the BPMS would use the URL to execute the decision service. Another advantage of the Decision Model is the ease in which analyst/designer can use the model or parts of the model to create decision services that can be executed by any process-based information system. An advantage of a BDMS is that the same decision model can be deployed in multiple automation technologies, if necessary.

What Business Analysts need to Know to Work within the New IS Paradigm

The previous sections outlined and discussed the paradigm shift from developing the traditional database-driven systems (see Figure 1) to developing and executing process-based information systems (see Figure 3). This final section summarizes what business analysts need to know to work with process-based information systems. Again, the UGA MIS curriculum frames the discussion. The UGA MIS curriculum’s primary outcome is to develop business analyst skills.

The current and future UGA curriculum is shown in Figure 5. In 2008, Business Process Management (BPM) and Project Management became required courses. In 2011, the new curriculum was extended to four semesters by requiring students to take all five required courses before taking the required Business Systems Analysis and Design course. Figure 5 includes two future changes the MISDepartmentis considering. One change is allowing students to take Advanced Business Process Management or Internet Programming as a required course, currently Advanced Business Process Management is an elective course. The other change is to add an elective course on the Decision Model/Business Rules. As of the spring semester 2012, UGA MIS major is comprised of six required courses and one elective. For a detailed description of curriculum and courses,see http://www.terry.uga.edu/mis/ .

Naturally, database management remains a required core course. Business analysts still need to be solidly grounded in the relational data model, data modeling and the use of database management systems. The two programming courses also remain as required courses. Business analysts still need a basic understanding of programming, especially Java programming, thus, the required first course in programming. The basic knowledge in Java programming is helpful in using and understanding the BPMS and BDMS/BRMS tools since most of these tools were developed in Java.

The major changes for the paradigm shift to process-based information systems are in the two BPM courses.The general outcome of the first BPM course, required of all MIS majors, is to improve student’s understanding and skills in terms of modeling, improving and managing organizational work systems, especially the understanding of the process and technology components of these systems. The course focuses on BPM both as management discipline and as a technology (BPMS). In this article, the focus has been on BPMS. BPM as a management approach defines an organization as a collection of processes focused on customer satisfaction, managing process using well-defined measures, and continually improving processes. The purpose of BPMS and the other technology shown in Figure 3 is to enable more effective BPM.

The BPM course covers a gamut of topics from process management, business process analysis, modeling (BPMN) and simulation to BPMS implementation, the use of web services, and process redesign methodologies. The heart of the course is process modeling using the BPMN modeling language.

The second course, Advanced BPM, focuses on BPMS, SOA (Service-oriented architectures) and BDMS (Business Decision/Rules Management Systems) as a new environment for developing and executing process-based information systems. Students build a number of systems using a commercial BPMS_SOA_BDMS environment. SOA service model is introduced in the first course but is covered in more depth in the second course. The same is true for the Decision Model and BDMS. The business analyst needs a basic understanding of SOA principles and their implementation in Web services including the selection and use of Web services. As indicated in the previous section, it is apparent that the Decision Model is going to become the dominant model in the business rules area and BDMS the dominant technology.The basics of this model and the technology are covered in the two BPM courses. However, there is enough important material to offer a full course elective on this topic, and thus, the proposed elective course in the curriculum.

The Advanced BPM course is currently an elective in the UGA curriculum. In Figure 5 this course is shown as an optional required course because it will be included as such in the near future. The optional required course placement reflects the current state of information systems development. The new BPMS_SOA_BDMS environment provides a new development and execution platform where systems are composed based on existing services. The second programming course reflects the traditional building your own systems. This ‘built” approach will not go away but will slowly transition to building services that will be used to in composing process-based information systems instead of building application systems. In the beginning, all IS development took the “build” approach given the technology tools available. The “built” period was followed by a focus on buying applications especially for non-core systems, particularly in the form of ERP systems.

In early 2012, the companies hiring UGA MIS students are still primarily interested in ‘built” and “buy” approaches which is why we have not made the Advanced BPM an optional required course yet. As companies move into the BPMS_SOA_BDMS environment, outlined in this article, and focus shifts more fully to a “compose” approach, the Advanced BPM will become an optional requirement course allowing students to focus on “built” or “compose” approach to system development. This transition to a “composed” approach is happening quite quickly. The major roadblock is the lack of trained personnel. The Business Systems Analysis & Design course has also been modified to include this “compose” approach with the traditional “build” and “buy” system development approaches.

Finally, the most important knowledge a business analyst needs to have to succeed within this new IS paradigm is an understanding of the four core models: BPMN process model, Decision Model, Relational Data Model and the SOA Service Model. These four models are all technology-independent but all are easily implemented in technology. Understanding the models provides the best mechanism for understanding and utilizing the technology that implements them. A general knowledge of the SOA Service Model is important but a detailed knowledge is not necessary because this model has many technical aspects that are not essential to the business analyst. However, a detailed understanding of the other three models (BPMN, Decision and Relational) is essential for the business analyst. The reason for this is that these three models provide critical bridges between the worlds of business and IT through the use of a common models and languages that can be used to develop shared models used by both groups.

The problem with most information systems academic programs is that they have not made the changes to implement the paradigm shift that is described in this article. Most programs look more like the one in Figure 2, rather than the curriculum we just described in Figure 5 . There are a number of training programs available to help develop the skills reflected in the courses shown in Figure 5[2] .

The new breed of information systems, depicted in Figure 3, provides the technology environment for business analysts to model and automate the essential business and decision processes which impact the quality and effectiveness of our work and our lives. As academics, business analysts, MIS professionals and business managers, we must all learn the critical models and the skills and technology necessary to move this new paradigm forward. This article has provided some first teps to facilitate the exciting information systems paradigm shift that stands in front of us.

Author : Robert Bostrom (edited by Barbara von Halle)

Dr. Bob Bostrom is President of Bostrom & Associates, an Athens-based training and consulting company focusing on facilitation and the effective integration of people and technology. For 22 years he taught and contributed significant research at the University of Georgia where he held the chaired position of the L. Edmund Rast Professor of Business. He designed and taught numerous classes in Management Information Systems (MIS), Management and Leadership for undergraduate, graduate and Ph.D students. Dr. Bostrom holds a B.A. in Chemistry and M.B.A. from Michigan State University, an M.S. in Computer Science from SUNY at Albany, and a Ph.D. in MIS from the University of Minnesota. Besides abundant publications in leading academic and practitioner journals, he has extensive consulting and training experience. His current research and consulting interests are focused on Business Process Management (BPM), high-performing individuals, facilitation, technology-supported learning, and effective design of organizations via integrating human and technological dimensions. He now holds the title of Professor Emeritus at the University of Georgia and continues to teach advance BPM courses and mentor students and colleagues.

Barbara von Halle is Managing Partner of Knowledge Partners International, LLC (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach Publications/Taylor and Francis LLC 2009.

[1]For a listing of academic programs that have addressed this new breed of process-based information systems, see http://www.bptrends.com/resources_organizations.cfm?organizationTypeID=2F5802DD-3048-C0CF-057584B8675B9A1A. [2]One of the best and most comprehensive is the BPM Institute training program, see http://www.bpminstitute.org/training . References

Database Management Systems

 For good overview, see http://en.wikipedia.org/wiki/Database_management_system

 There are many good textbooks; the one I would recommend is Data Management: Databases & Organizations, 5th Edition, by Richard T. Watson (The Univ. of Georgia), 2006, see http://www.richardtwatson.com/dm5e/

Business Process Management Systems (BPMS) and Business Process Modeling Notation (BPMN)

 A great introduction to BPMN by Bruce Silver can be found at http://wiki.sdn.sap.com/wiki/display/BPX/Process+Modeling+With+BPMN Delivered in six 20-minute segments of Flash video, this course explains all of the diagram patterns important to process modeling with BPMN and how BPMN is used in conjunction with executable process design.

Silver, Bruce, BPMN Method & Style with Implementer’s Guide, 2nd Edition, Cody-Cassidy Press, Aptos, CA, 2011 (Amazon: http://www.amazon.com/Method-Style-Edition-Implementers-Guide/dp/0982368119/ref=sr_1_1?ie=UTF8&qid=1336326893&sr=8-1 ) Also check his blog, BPMS Watch, http://www.brsilver.com/

 Harmon, Paul, “Once More: What is BPM” http://www.bptrends.com/publicationfiles/advisor20100615.pdf   Paul’s web site and newsletter are also a great resource http://www.bptrends.com

 Harmon, Paul, “Where Does BPMS Fit Into BPM?, http://www.bptrends.com/publicationfiles/advisor20110426.pdf

 BPM Basics for Dummies, http://www.softwareag.com/corporate/res/books/bpm_for_dummies/default.asp

Service Oriented Architecture (SOA)

Two minute video SOA overview: http://www.youtube.com/watch?v=zV860odGN5Y

  SOA Adoption for Dummies

 Good book covering major SOA topics: Applied SOA: Service-Oriented Architecture and Design Strategies [Paperback], Michael Rosen (Author), Boris Lublinsky (Author), Kevin T. Smith (Author), Marc J. Balcer (Author),

Business Rule and the Decision Model

Silver, Bruce, “Driving Agility and PerformanceWith BPM and Business Rules”, http://www.techie.techieindex.com/techie/whitepapers/wp_details.jsp?id=1786

The best detailed discussion of Decision Model and its relationship to other models discuss in this paper see book: The Decision Model: A Business Logic Framework Linking Business and Technology (IT Management) [Hardcover] Barbara von Halle (Author), Larry Goldberg (Author); for introduction to Decision Model, see primer article http://kpiusa.com/index.php/The-Decision-Model/the-decision-model.html (see this site for other Decision Model resources)

Other Useful Links

  http://www.bpminstitute.org/index.php Great place for resources and trainings on all topics in the paper.

http://www.bptrends.com/index.cfm Another excellent site for resources. Excellent newsletter as well!

 Excellent summary report on Business Rule Management Systems (BRMS) http://www.bptrends.com/reports_toc_03.cfm

 Excellent summary report on Business Process Management Systems (BPMS) http://www.bptrends.com/reports_toc_01.cfm

http://www.bpmbasics.com/ This site excellent site of BPM resources. It also has an excellent newsletter you can subscribe to.

 http://www.abpmp.org/ The Association of BPM Professionals is a non-profit, vendor independent professional organization dedicated to the advancement of BPM concepts and its practices. It is practitioner-oriented and practitioner-led.

Related Articles

Article/Paper Categories

Upcoming live webinars, ace the interview.

Roles and Titles

• Business Analyst
• Business Process Analyst
• IT Business Analyst
• Requirements Engineer
• Business Systems Analyst
• Systems Analyst
• Data Analyst

Career Resources

• Interview Tips
• Salary Information
• Directory of Links

Community Resources

• Project Members

Advertising Opportunities  | Contact Us  | Privacy Policy

Adopting the right problem-solving approach

May 4, 2023 You’ve defined your problem, ensured stakeholders are aligned, and are ready to bring the right problem-solving approach and focus to the situation to find an optimal solution. But what is the right problem-solving approach? And what if there is no single ideal course of action? In our 2013 classic  from the Quarterly , senior partner Olivier Leclerc  highlights the value of taking a number of different approaches simultaneously to solve difficult problems. Read on to discover the five flexons, or problem-solving languages, that can be applied to the same problem to generate richer insights and more innovative solutions. Then check out more insights on problem-solving approaches, and dive into examples of pressing challenges organizations are contending with now.

Five routes to more innovative problem solving

Author Talks: Get on the performance curve

Strategy to beat the odds

How to master the seven-step problem-solving process

Want better strategies? Become a bulletproof problem solver

Digital performance management: From the front line to the bottom line

Addressing employee burnout: Are you solving the right problem?

Business’s ‘It’s not my problem’ IT problem

TEST YOUR SKILLS

Take the McKinsey Problem Solving Test

Solve, McKinsey’s assessment game

• The Art of Effective Problem Solving: A Step-by-Step Guide
• Learn Lean Sigma
• Problem Solving

Whether we realise it or not, problem solving skills are an important part of our daily lives. From resolving a minor annoyance at home to tackling complex business challenges at work, our ability to solve problems has a significant impact on our success and happiness. However, not everyone is naturally gifted at problem-solving, and even those who are can always improve their skills. In this blog post, we will go over the art of effective problem-solving step by step.

You will learn how to define a problem, gather information, assess alternatives, and implement a solution, all while honing your critical thinking and creative problem-solving skills. Whether you’re a seasoned problem solver or just getting started, this guide will arm you with the knowledge and tools you need to face any challenge with confidence. So let’s get started!

Table of Contents

Problem solving methodologies.

Individuals and organisations can use a variety of problem-solving methodologies to address complex challenges. 8D and A3 problem solving techniques are two popular methodologies in the Lean Six Sigma framework.

Methodology of 8D (Eight Discipline) Problem Solving:

The 8D problem solving methodology is a systematic, team-based approach to problem solving. It is a method that guides a team through eight distinct steps to solve a problem in a systematic and comprehensive manner.

The 8D process consists of the following steps:

• Form a team: Assemble a group of people who have the necessary expertise to work on the problem.
• Define the issue: Clearly identify and define the problem, including the root cause and the customer impact.
• Create a temporary containment plan: Put in place a plan to lessen the impact of the problem until a permanent solution can be found.
• Identify the root cause: To identify the underlying causes of the problem, use root cause analysis techniques such as Fishbone diagrams and Pareto charts.
• Create and test long-term corrective actions: Create and test a long-term solution to eliminate the root cause of the problem.
• Implement and validate the permanent solution: Implement and validate the permanent solution’s effectiveness.
• Prevent recurrence: Put in place measures to keep the problem from recurring.
• Recognize and reward the team: Recognize and reward the team for its efforts.

Download the 8D Problem Solving Template

A3 Problem Solving Method:

The A3 problem solving technique is a visual, team-based problem-solving approach that is frequently used in Lean Six Sigma projects. The A3 report is a one-page document that clearly and concisely outlines the problem, root cause analysis, and proposed solution.

The A3 problem-solving procedure consists of the following steps:

• Determine the issue: Define the issue clearly, including its impact on the customer.
• Perform root cause analysis: Identify the underlying causes of the problem using root cause analysis techniques.
• Create and implement a solution: Create and implement a solution that addresses the problem’s root cause.
• Monitor and improve the solution: Keep an eye on the solution’s effectiveness and make any necessary changes.

Subsequently, in the Lean Six Sigma framework, the 8D and A3 problem solving methodologies are two popular approaches to problem solving. Both methodologies provide a structured, team-based problem-solving approach that guides individuals through a comprehensive and systematic process of identifying, analysing, and resolving problems in an effective and efficient manner.

Step 1 – Define the Problem

The definition of the problem is the first step in effective problem solving. This may appear to be a simple task, but it is actually quite difficult. This is because problems are frequently complex and multi-layered, making it easy to confuse symptoms with the underlying cause. To avoid this pitfall, it is critical to thoroughly understand the problem.

To begin, ask yourself some clarifying questions:

• What exactly is the issue?
• What are the problem’s symptoms or consequences?
• Who or what is impacted by the issue?
• When and where does the issue arise?

Answering these questions will assist you in determining the scope of the problem. However, simply describing the problem is not always sufficient; you must also identify the root cause. The root cause is the underlying cause of the problem and is usually the key to resolving it permanently.

Try asking “why” questions to find the root cause:

• What causes the problem?
• Why does it continue?
• Why does it have the effects that it does?

By repeatedly asking “ why ,” you’ll eventually get to the bottom of the problem. This is an important step in the problem-solving process because it ensures that you’re dealing with the root cause rather than just the symptoms.

Once you have a firm grasp on the issue, it is time to divide it into smaller, more manageable chunks. This makes tackling the problem easier and reduces the risk of becoming overwhelmed. For example, if you’re attempting to solve a complex business problem, you might divide it into smaller components like market research, product development, and sales strategies.

To summarise step 1, defining the problem is an important first step in effective problem-solving. You will be able to identify the root cause and break it down into manageable parts if you take the time to thoroughly understand the problem. This will prepare you for the next step in the problem-solving process, which is gathering information and brainstorming ideas.

Step 2 – Gather Information and Brainstorm Ideas

Gathering information and brainstorming ideas is the next step in effective problem solving. This entails researching the problem and relevant information, collaborating with others, and coming up with a variety of potential solutions. This increases your chances of finding the best solution to the problem.

Begin by researching the problem and relevant information. This could include reading articles, conducting surveys, or consulting with experts. The goal is to collect as much information as possible in order to better understand the problem and possible solutions.

Next, work with others to gather a variety of perspectives. Brainstorming with others can be an excellent way to come up with new and creative ideas. Encourage everyone to share their thoughts and ideas when working in a group, and make an effort to actively listen to what others have to say. Be open to new and unconventional ideas and resist the urge to dismiss them too quickly.

Finally, use brainstorming to generate a wide range of potential solutions. This is the place where you can let your imagination run wild. At this stage, don’t worry about the feasibility or practicality of the solutions; instead, focus on generating as many ideas as possible. Write down everything that comes to mind, no matter how ridiculous or unusual it may appear. This can be done individually or in groups.

Once you’ve compiled a list of potential solutions, it’s time to assess them and select the best one. This is the next step in the problem-solving process, which we’ll go over in greater detail in the following section.

Step 3 – Evaluate Options and Choose the Best Solution

Once you’ve compiled a list of potential solutions, it’s time to assess them and select the best one. This is the third step in effective problem solving, and it entails weighing the advantages and disadvantages of each solution, considering their feasibility and practicability, and selecting the solution that is most likely to solve the problem effectively.

To begin, weigh the advantages and disadvantages of each solution. This will assist you in determining the potential outcomes of each solution and deciding which is the best option. For example, a quick and easy solution may not be the most effective in the long run, whereas a more complex and time-consuming solution may be more effective in solving the problem in the long run.

Consider each solution’s feasibility and practicability. Consider the following:

• Can the solution be implemented within the available resources, time, and budget?
• What are the possible barriers to implementing the solution?
• Is the solution feasible in today’s political, economic, and social environment?

You’ll be able to tell which solutions are likely to succeed and which aren’t by assessing their feasibility and practicability.

Finally, choose the solution that is most likely to effectively solve the problem. This solution should be based on the criteria you’ve established, such as the advantages and disadvantages of each solution, their feasibility and practicability, and your overall goals.

It is critical to remember that there is no one-size-fits-all solution to problems. What is effective for one person or situation may not be effective for another. This is why it is critical to consider a wide range of solutions and evaluate each one based on its ability to effectively solve the problem.

Step 4 – Implement and Monitor the Solution

When you’ve decided on the best solution, it’s time to put it into action. The fourth and final step in effective problem solving is to put the solution into action, monitor its progress, and make any necessary adjustments.

To begin, implement the solution. This may entail delegating tasks, developing a strategy, and allocating resources. Ascertain that everyone involved understands their role and responsibilities in the solution’s implementation.

Next, keep an eye on the solution’s progress. This may entail scheduling regular check-ins, tracking metrics, and soliciting feedback from others. You will be able to identify any potential roadblocks and make any necessary adjustments in a timely manner if you monitor the progress of the solution.

Finally, make any necessary modifications to the solution. This could entail changing the solution, altering the plan of action, or delegating different tasks. Be willing to make changes if they will improve the solution or help it solve the problem more effectively.

It’s important to remember that problem solving is an iterative process, and there may be times when you need to start from scratch. This is especially true if the initial solution does not effectively solve the problem. In these situations, it’s critical to be adaptable and flexible and to keep trying new solutions until you find the one that works best.

To summarise, effective problem solving is a critical skill that can assist individuals and organisations in overcoming challenges and achieving their objectives. Effective problem solving consists of four key steps: defining the problem, generating potential solutions, evaluating alternatives and selecting the best solution, and implementing the solution.

You can increase your chances of success in problem solving by following these steps and considering factors such as the pros and cons of each solution, their feasibility and practicability, and making any necessary adjustments. Furthermore, keep in mind that problem solving is an iterative process, and there may be times when you need to go back to the beginning and restart. Maintain your adaptability and try new solutions until you find the one that works best for you.

• Novick, L.R. and Bassok, M., 2005.  Problem Solving . Cambridge University Press.

Daniel Croft

Daniel Croft is a seasoned continuous improvement manager with a Black Belt in Lean Six Sigma. With over 10 years of real-world application experience across diverse sectors, Daniel has a passion for optimizing processes and fostering a culture of efficiency. He's not just a practitioner but also an avid learner, constantly seeking to expand his knowledge. Outside of his professional life, Daniel has a keen Investing, statistics and knowledge-sharing, which led him to create the website learnleansigma.com, a platform dedicated to Lean Six Sigma and process improvement insights.

Fishbone Diagram Or 5 Whys Analysis: Which Should You Use?

8d (8 disciplines), free lean six sigma templates.

Improve your Lean Six Sigma projects with our free templates. They're designed to make implementation and management easier, helping you achieve better results.

5S Floor Marking Best Practices

In lean manufacturing, the 5S System is a foundational tool, involving the steps: Sort, Set…

How to Measure the ROI of Continuous Improvement Initiatives

When it comes to business, knowing the value you’re getting for your money is crucial,…

8D Problem-Solving: Common Mistakes to Avoid

In today’s competitive business landscape, effective problem-solving is the cornerstone of organizational success. The 8D…

The Evolution of 8D Problem-Solving: From Basics to Excellence

In a world where efficiency and effectiveness are more than just buzzwords, the need for…

8D: Tools and Techniques

Are you grappling with recurring problems in your organization and searching for a structured way…

How to Select the Right Lean Six Sigma Projects: A Comprehensive Guide

Going on a Lean Six Sigma journey is an invigorating experience filled with opportunities for…

• Miles Anthony Smith
• Sep 12, 2022
• 12 min read

The Ultimate Problem-Solving Process Guide: 31 Steps and Resources

Updated: Jan 24, 2023

GOT CHALLENGES WITH YOUR PROBLEM-SOLVING PROCESS? ARE YOU FRUSTRATED?

prob·lem-solv·ing noun -the process of finding solutions to difficult or complex issues. It sounds so simple, doesn’t it? But in reality problem-solving is hard. It's almost always more complex than it seems. That's why problem-solving can be so frustrating sometimes. You can feel like you’re spinning your wheels, arguing in circles, or just failing to find answers that actually work. And when you've got a group working on a problem, it can get even muddier …differences of opinions, viewpoints colored by different backgrounds, history, life experiences, you name it. We’re all looking at life and work from different angles, and that often means disagreement. Sometimes sharp disagreement. That human element, figuring out how to take ourselves out of the equation and make solid, fact-based decisions , is precisely why there’s been so much written on problem-solving. Which creates its own set of problems. Whose method is best? How can you possibly sift through them all? Are we to have one person complete the entire problem-solving process by themselves or rely on a larger team to find answers to our most vexing challenges in the workplace ? Today, we’re going to make sense of it all. We’ll take a close look at nine top problem-solving methods. Then we’ll grab the best elements of all of them to give you a process that will have your team solving problems faster, with better results , and maybe with less sharp disagreement. Ready to dive in? Let’s go!

9 PROFITABLE PROBLEM-SOLVING TECHNIQUES AND METHODS

While there are loads of methods to choose from, we are going to focus on nine of the more common ones. You can use some of these problem-solving techniques reactively to solve a known issue or proactively to find more efficient or effective ways of performing tasks. If you want to explore other methods, check out this resource here . A helpful bit of advice here is to reassure people that you aren’t here to identify the person that caused the problem . You’re working to surface the issue, solve it and make sure it doesn’t happen again, regardless of the person working on the process. It can’t be understated how important it is to continually reassure people of this so that you get unfiltered access to information. Without this, people will often hide things to protect themselves . After all, nobody wants to look bad, do they? With that said, let’s get started...

1. CREATIVE PROBLEM SOLVING (CPS)

Alex Osborn coined the term “Creative Problem Solving” in the 1940s with this simple four-step process:

Clarify : Explore the vision, gather data, and formulate questions.

Ideate : This stage should use brainstorming to generate divergent thinking and ideas rather than the random ideas normally associated with brainstorming.

Develop : Formulate solutions as part of an overall plan.

Implement : Put the plan into practice and communicate it to all parties.

2. APPRECIATIVE INQUIRY

Source: http://www.davidcooperrider.com/ai-process/ This method seeks, first and foremost, to identify the strengths in people and organizations and play to that “positive core” rather than focus our energies on improving weaknesses . It starts with an “affirmative topic,” followed by the “positive core (strengths).” Then this method delves into the following stages:

Discovery (fact-finding)

Dream (visioning the future)

Design (strategic purpose)

Destiny (continuous improvement)

3. “FIVE WHYS” METHOD

This method simply suggests that we ask “Why” at least five times during our review of the problem and in search of a fix. This helps us dig deeper to find the the true reason for the problem, or the root cause. Now, this doesn’t mean we just keeping asking the same question five times. Once we get an answer to our first “why”, we ask why to that answer until we get to five “whys”.

Using the “five whys” is part of the “Analyze” phase of Six Sigma but can be used with or without the full Six Sigma process.

Review this simple Wikipedia example of the 5 Whys in action:

The vehicle will not start. (the problem)

Why? - The battery is dead. (First why)

Why? - The alternator is not functioning. (Second why)

Why? - The alternator belt has broken. (Third why)

Why? - The alternator belt was well beyond its useful service life and not replaced. (Fourth why)

Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

4. LEAN SIX SIGMA (DMAIC METHOD)

While many people have at least heard of Lean or Six Sigma, do we know what it is? Like many problem-solving processes, it has five main steps to follow.

Define : Clearly laying out the problem and soliciting feedback from those who are customers of the process is necessary to starting off on the right foot.

Measure : Quantifying the current state of the problem is a key to measuring how well the fix performed once it was implemented.

Analyze : Finding out the root cause of the problem (see number 5 “Root Cause Analysis” below) is one of the hardest and least explored steps of Six Sigma.

Improve : Crafting, executing, and testing the solution for measureable improvement is key. What doesn’t get implemented and measured really won’t make a difference.

Control : Sustaining the fix through a monitoring plan will ensure things continue to stay on track rather than being a short-lived solution.

5. ROOT CAUSE ANALYSIS

Compared to other methods, you’ll more often find this technique in a reactive problem-solving mode, but it is helpful nonetheless. Put simply, it requires a persistent approach to finding the highest-level cause, since most reasons you’ll uncover for a problem don’t tell the whole story.

Most of the time, there are many factors that contributed to an issue. The main reason is often shrouded in either intentional or unintentional secrecy. Taking the time to drill down to the root of the issue is key to truly solving the problem.

6. DEMING-SHEWHART CYCLE: PLAN-DO-CHECK-ACT (PDCA)

Named for W. Edwards Deming and Walter A. Shewhart, this model follows a four-step process:

Plan: Establish goals and objectives at the outset to gain agreement. It’s best to start on a small scale in order to test results and get a quick win.

Do: This step is all about the implementation and execution of the solution.

Check: Study and compare actual to expected results. Chart this data to identify trends.

Act/Adjust: If the check phase showed different results, then adjust accordingly. If worse than expected, then try another fix. If the same or better than expected, then use that as the new baseline for future improvements.

7. 8D PROBLEM-SOLVING

While this is named “8D” for eight disciplines, there are actually nine , because the first is listed as step zero. Each of the disciplines represents a phase of this process. Its aim is to implement a quick fix in the short term while working on a more permanent solution with no recurring issues.

Prepare and Plan : Collecting initial information from the team and preparing your approach to the process is a necessary first step.

Form a Team : Select a cross-functional team of people, one leader to run meetings and the process, and one champion/sponsor who will be the final decision-maker.

Describe the Problem : Using inductive and deductive reasoning approaches, lay out the precise issue to be corrected.

Interim Containment Action : Determine if an interim solution needs to be implemented or if it can wait until the final fix is firmed up. If necessary, the interim action is usually removed once the permanent solution is ready for implementation.

Root Cause Analysis and Escape Point : Finding the root of the issue and where in the process it could’ve been found but was not will help identify where and why the issue happened.

Permanent Corrective Action : Incorporating key criteria into the solution, including requirements and wants, will help ensure buy-in from the team and your champion.

Implement and Validate the Permanent Corrective Action : Measuring results from the fix implemented validates it or sends the team back to the drawing board to identity a more robust solution.

Prevent Recurrence : Updating work procedure documents and regular communication about the changes are important to keep old habits in check.

Closure and Team Celebration : Taking time to praise the team for their efforts in resolving the problem acknowledges the part each person played and offers a way to move forward.

8. ARMY PROBLEM SOLVING PROCESS

The US Army has been solving problems for more than a couple of centuries , so why not take a look at the problem-solving process they’ve refined over many years? They recommend this five step process:

Identify the Problem : Take time to understand the situation and define a scope and limitations before moving forward.

Gather Information : Uncover facts, assumptions, and opinions about the problem, and challenge them to get to the truth.

Develop Screening and Evaluation Criteria :

Five screening items should be questioned. Is it feasible, acceptable, distinguishable, and complete?

Evaluation criteria should have these 5 elements: short title, definition, unit of measure, benchmark, and formula.

Generate, Analyze, and Compare Possible Solutions : Most fixes are analyzed, but do you compare yours to one another as a final vetting method?

Choose a Solution and Implement : Put the fix into practice and follow up to ensure it is being followed consistently and having the desired effect.

9. HURSON'S PRODUCTIVE THINKING MODEL

Tim Hurson introduced this model in 2007 with his book, Think Better. It consists of the following six actions.

Ask "What is going on?" : Define the impact of the problem and the aim of its solution.

Ask "What is success?" : Spell out the expected outcome, what should not be in fix, values to be considered, and how things will be evaluated.

Ask "What is the question?" : Tailor questions to the problem type. Valuable resources can be wasted asking questions that aren’t truly relevant to the issue.

Generate answers : Prioritize answers that are the most relevant to solutions, without excluding any suggestion to present to the decision-makers.

Forge the solution : Refine the raw list of prioritized fixes, looking for ways to combine them for a more powerful solution or eliminate fixes that don’t fit the evaluation criteria.

Align resources: Identify resources, team, and stakeholders needed to implement and maintain the solution.

STEAL THIS THOROUGH 8-STEP PROBLEM-SOLVING PROCESS

Now that we’ve reviewed a number of problem-solving methods, we’ve compiled the various steps into a straightforward, yet in-depth, s tep-by-step process to use the best of all methods.

1. DIG DEEP: IDENTIFY, DEFINE, AND CLARIFY THE ISSUE

“Elementary, my dear Watson,” you might say.

This is true, but we often forget the fundamentals before trying to solve a problem. So take some time to gain understanding of critical stakeholder’s viewpoints to clarify the problem and cement consensus behind what the issue really is.

Sometimes it feels like you’re on the same page, but minor misunderstandings mean you’re not really in full agreement.. It’s better to take the time to drill down on an issue before you get too far into solving a problem that may not be the exact problem . Which leads us to…

2. DIG DEEPER: ROOT CAUSE ANALYSIS

This part of the process involves identifying these three items :

What happened?

Why did it happen?

What process do we need to employ to significantly reduce the chances of it happening again ?

You’ll usually need to sort through a series of situations to find the primary cause. So be careful not to stop at the first cause you uncover . Dig further into the situation to expose the root of the issue. We don’t want to install a solution that only fixes a surface-level issue and not the root. T here are typically three types of causes :

Physical: Perhaps a part failed due to poor design or manufacturing.

Human error: A person either did something wrong or didn’t do what needed to be done.

Organizational: This one is mostly about a system, process, or policy that contributed to the error .

When searching for the root cause, it is important to ensure people that you aren’t there to assign blame to a person but rather identify the problem so a fix can prevent future issues.

3. PRODUCE A VARIETY OF SOLUTION OPTIONS

So far, you’ve approached the problem as a data scientist, searching for clues to the real issue. Now, it’s important to keep your eyes and ears open, in case you run across a fix suggested by one of those involved in the process failure. Because they are closest to the problem, they will often have an idea of how to fix things. In other cases, they may be too close, and unable to see how the process could change.

The bottom line is to solicit solution ideas from a variety of sources , both close to and far away from the process you’re trying to improve.

You just never know where the top fix might come from!

4. FULLY EVALUATE AND SELECT PLANNED FIX(ES)

Evaluating solutions to a defined problem can be tricky since each one will have cost, political, or other factors associated with it. Running each fix through a filter of cost and impact is a vital step toward identifying a solid solution and hopefully settling on the one with the highest impact and low or acceptable cost.

Categorizing each solution in one of these four categoriescan help teams sift through them:

High Cost/Low Impact: Implement these last, if at all, since t hey are expensive and won’t move the needle much .

Low Cost/Low Impact: These are cheap, but you won’t get much impact.

High Cost/High Impact: These can be used but should be second to the next category.

Low Cost/High Impact: Getting a solid “bang for your buck” is what these fixes are all about. Start with these first .

5. DOCUMENT THE FINAL SOLUTION AND WHAT SUCCESS LOOKS LIKE

Formalize a document that all interested parties (front-line staff, supervisors, leadership, etc.) agree to follow. This will go a long way towards making sure everyone fully understands what the new process looks like, as well as what success will look like .

While it might seem tedious, try to be overly descriptive in the explanation of the solution and how success will be achieved. This is usually necessary to gain full buy-in and commitment to continually following the solution. We often assume certain things that others may not know unless we are more explicit with our communications.

6. SUCCESSFULLY SELL AND EXECUTE THE FIX

Arriving at this stage in the process only to forget to consistently apply the solution would be a waste of time, yet many organizations fall down in the execution phase . Part of making sure that doesn’t happen is to communicate the fix and ask for questions multiple times until all parties have a solid grasp on what is now required of them.

One often-overlooked element of this is the politics involved in gaining approval for your solution. Knowing and anticipating objections of those in senior or key leadership positions is central to gaining buy-in before fix implementation.

7. RINSE AND REPEAT: EVALUATE, MONITOR, AND FOLLOW UP

Next, doing check-ins with the new process will ensure that the solution is working (or identity if further reforms are necessary) . You’ll also see if the measure of predefined success has been attained (or is making progress in that regard).

Without regularly monitoring the fix, you can only gauge the success or failure of the solution by speculation and hearsay. And without hard data to review, most people will tell their own version of the story.

8. COLLABORATIVE CONTINGENCIES, ITERATION, AND COURSE CORRECTION

Going into any problem-solving process, we should take note that we will not be done once the solution is implemented (or even if it seems to be working better at the moment). Any part of any process will always be subject to the need for future iterations and course corrections . To think otherwise would be either foolish or naive.

There might need to be slight, moderate, or wholesale changes to the solution previously implemented as new information is gained, new technologies are discovered, etc.

14 FRUITFUL RESOURCES AND EXERCISES FOR YOUR PROBLEM-SOLVING JOURNEY

Want to test your problem-solving skills?

Take a look at these twenty case study scenario exercises to see how well you can come up with solutions to these problems.

Still have a desire to discover more about solving problems?

Check out these 14 articles and books...

1. THE LEAN SIX SIGMA POCKET TOOLBOOK: A QUICK REFERENCE GUIDE TO NEARLY 100 TOOLS FOR IMPROVING QUALITY AND SPEED

This book is like a Bible for Lean Six Sigma , all in a pocket-sized package.

2. SOME SAGE PROBLEM SOLVING ADVICE

The American Society for Quality has a short article on how it’s important to focus on the problem before searching for a solution.

3. THE SECRET TO BETTER PROBLEM SOLVING: HARVARD BUSINESS REVIEW

Wondering if you are solving the right problems? Check out this Harvard Business Review article.

4. PROBLEM SOLVING 101 : A SIMPLE BOOK FOR SMART PEOPLE

Looking for a fun and easy problem-solving book that was written by a McKinsey consultant? Take a look!

5. THE BASICS OF CREATIVE PROBLEM SOLVING – CPS

If you want a deeper dive into the seven steps of Creative Problem Solving , see this article.

6. APPRECIATIVE INQUIRY : A POSITIVE REVOLUTION IN CHANGE

Appreciative Inquiry has been proven effective in organizations ranging from Roadway Express and British Airways to the United Nations and the United States Navy. Review this book to join the positive revolution.

7. PROBLEM SOLVING: NINE CASE STUDIES AND LESSONS LEARNED

The Seattle Police Department has put together nine case studies that you can practice solving . While they are about police work, they have practical application in the sleuthing of work-related problems.

8. ROOT CAUSE ANALYSIS : THE CORE OF PROBLEM SOLVING AND CORRECTIVE ACTION

Need a resource to delve further into Root Cause Analysis? Look no further than this book for answers to your most vexing questions .

9. SOLVING BUSINESS PROBLEMS : THE CASE OF POOR FRANK

This solid case study illustrates the complexities of solving problems in business.

10. THE 8-DISCIPLINES PROBLEM SOLVING METHODOLOGY

Learn all about the “8Ds” with this concise primer.

11. THE PROBLEM-SOLVING PROCESS THAT PREVENTS GROUPTHINK HBR

Need to reduce groupthink in your organization’s problem-solving process ? Check out this article from the Harvard Business Review.

12. THINK BETTER : AN INNOVATOR'S GUIDE TO PRODUCTIVE THINKING

Tim Hurson details his own Productive Thinking Model at great length in this book from the author.

13. 5 STEPS TO SOLVING THE PROBLEMS WITH YOUR PROBLEM SOLVING INC MAGAZINE

This simple five-step process will help you break down the problem, analyze it, prioritize solutions, and sell them internally.

14. CRITICAL THINKING : A BEGINNER'S GUIDE TO CRITICAL THINKING, BETTER DECISION MAKING, AND PROBLEM SOLVING!

LOOKING FOR ASSISTANCE WITH YOUR PROBLEM-SOLVING PROCESS?

There's a lot to take in here, but following some of these methods are sure to improve your problem-solving process. However, if you really want to take problem-solving to the next level, InitiativeOne can come alongside your team to help you solve problems much faster than you ever have before.

There are several parts to this leadership transformation process provided by InitiativeOne, including a personal profile assessment, cognitive learning, group sessions with real-world challenges, personal discovery, and a toolkit to empower leaders to perform at their best.

There are really only two things stopping good teams from being great. One is how they make decisions and two is how they solve problems. Contact us today to grow your team’s leadership performance by making decisions and solving problems more swiftly than ever before!

• Featured Post

Recent Posts

Does Your Leadership Deserve Two Thumbs Up?

3 Ways to Harness the Power of Inspiration

Leadership Self-Check

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architects.

View an example

We protect your privacy.

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

• English edition
• Chinese edition
• Japanese edition
• French edition

Back to login

Login with:

Don't have an infoq account, helpful links.

• About InfoQ
• InfoQ Editors
• Write for InfoQ
• About C4Media

Choose your language

Discover transformative insights to level up your software development decisions. Use code LIMITEDOFFERIDSBOSTON24 for an exclusive offer.

Get practical advice from senior developers to navigate your current dev challenges. Use code LIMITEDOFFERIDSMUNICH24 for an exclusive offer.

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage News Challenges and Solutions for Building Machine Learning Systems

Challenges and Solutions for Building Machine Learning Systems

May 09, 2024 4 min read

Ben Linders

Infoq article contest.

According to Camilla Montonen, the challenges of building machine learning systems have to do mostly with creating and maintaining the model. MLOps platforms and solutions contain components needed to build machine systems, but MLOps is not about the tools; it is a culture and a set of practices. Montonen suggests that we should bridge the divide between practices of data science and machine learning engineering.

Camilla Montonen spoke about building machine learning systems at NDC Oslo 2023 .

Challenges that come with deploying machine learning systems to production include how to clean, curate and manage model training data, how to efficiently train and evaluate the model, and how to measure whether or not the model continues to perform well in production, Montonen said. Other challenges are how to calculate and serve the predictions the model makes on new data, how to handle missing and corrupted data and edge cases, how and when to efficiently re-train this model, and how to version control and store these different versions, she added.

There is a set of common components that are usually part of a machine learning system, Montonen explained: a feature store, an experiment tracking system so that data scientists can easily version the various models that they produce, a model registry or model versioning system to keep track of which model is currently deployed to production, and a data quality monitoring system to detect when some issues with data quality might arise. These components are now part of many MLOps platforms and solutions that are available on the market, she added.

Montonen argued that the tools and components do solve the problems for the systems they were designed for, but often fail to account for the fact that in a typical company, the evolution of a machine learning system is governed by factors that are often far outside of the realm of technical issues.

MLOps is not about the tools, it’s about the culture, Montonen claimed. It is not about just adding a model registry or a feature store to your stack, but about how the people who build and maintain your system interact with it, and reducing any and all friction points to a minimum, as she explained:

This can involve everything from thinking about git hygiene in your ML code repositories, designing how individual components of pipelines should be tested, thinking about how to keep feedback loops between data science experimentation environments and production environments, and maintaining a high standard of engineering throughout the code base.

We should strive towards bridging the divide between the practice of data science, which prioritizes rapid experimentation and iteration over robust production quality code, and the practice of machine learning engineering, which prioritizes version control, controlled delivery and deployment to production via CI/CD pipelines, automated testing and more thoughtfully crafted production code that is designed to be maintained over a longer period of time, Montonen said.

Instead of immediately adopting a bunch of MLOps tools that are more likely to complicate your problems instead of solving them, Montonen suggested going back to basics:

Begin with an honest diagnosis of why your machine learning team is struggling.

The largest gains in terms of data scientists’ development velocity and production reliability can be gained with a few surprisingly basic and simple investments into testing, CI/CD, and git hygiene, Montonen concluded.

InfoQ interviewed Camilla Montonen about building machine learning systems.

InfoQ: How well do the currently available MLOps tools and components solve the problem that software engineers are facing?

Camilla Montonen : Most big MLOps tooling providers grew out of projects started by engineers working on large language model training or computer vision model training, and are great for those use cases. They fail to account for the fact that in most small and medium sized companies that are not Big Tech, we are not training SOTA computer vision models; we’re building models to predict customer churn or help our users find interesting items. In these particular cases, these ready-made components are often not flexible enough to account for the many idiosyncrasies that accumulate in ML systems as time goes on.

InfoQ: What’s your advice to companies that are struggling with deploying their machine learning systems?

Montonen : Find out what your machine learning team is struggling with before introducing any tools or solutions. Is the code base complex? Are data scientists deploying ML pipeline code into production from their local machines, making it hard to keep track of which code changes are running in production? Is it hard to pinpoint what code changes are responsible for bugs that arise in production? Perhaps you need to invest in some refactoring and a proper CI/CD process and tooling. Are your new models performing worse in online A/B tests compared to your production models, but you have no insight into why this happens? Perhaps you need to invest in a simple dashboard that tracks key metrics. Having a diagnosis of your current problems will help you identify what tools will actually solve them and help you reason about tradeoffs. Most MLOps tools require some learning/maintenance/integration efforts so it is good to know that the problem you are solving with them is worth these tradeoffs.

About the Author

Rate this article, this content is in the culture & methods topic, related topics:.

• Culture & Methods
• AI, ML & Data Engineering
• Data Science
• Collaboration
• Agile Conferences
• Artificial Intelligence
• Machine Learning

Related Editorial

Related sponsored content, popular across infoq, you don’t need a css framework, amazon s3 unauthorized request billing issue: an empty s3 bucket can dramatically increase the costs, open-source apm and observability tool coroot now ga, 9 steps towards an agile architecture, security requires traveling the unhappy path - a conversation with robert hurlbut, polyglot programming with webassembly: a practical approach, related content, the infoq newsletter.

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example