MIS 301 Chapter 10 Study Guide

Vocabulary and key topics

Improved explanations of the main ideas

1) Chapter 10 is really about how managers make software decisions under uncertainty. Firms can build software, buy software, rent software, or mix these choices across different projects. The chapter makes clear that there is no one perfect choice for every situation. Good decisions depend on competitive advantage, risk, time, cost, skills, vendor quality, and legal constraints.

2) Systems development is not just programming. The slide deck says this directly: systems development involves all five IS components. That means success depends on hardware, software, data, procedures, and people together. A project can fail even if the code is fine, simply because requirements, training, testing, or process design were weak. :contentReference[oaicite:1]{index=1}

3) Requirements are the hardest and most important part of many projects. The “future role” and final slide emphasize that users must take responsibility for requirements. If business users do not clearly define what they need, developers may build something that is technically correct but operationally wrong. That is why the chapter keeps connecting project success to user involvement, testing, and scope management. :contentReference[oaicite:2]{index=2} :contentReference[oaicite:3]{index=3}

4) The project management triple constraint explains why software trade-offs are unavoidable. Scope, resources, and schedule pull against one another. If you expand scope, you usually need more time or more resources. If you compress the schedule, cost or quality pressure often rises. This is a core MIS management idea, not just a technical detail. :contentReference[oaicite:4]{index=4}

5) Waterfall sounds logical, but often breaks down in real business settings. Waterfall assumes firms can define all major requirements early and then move step-by-step. That can work in stable environments, but software projects often face moving requirements, changing technology, and user discovery along the way. That is why the slides call waterfall increasingly out of favor and responsible for many software fiascos. :contentReference[oaicite:5]{index=5}

6) Agile is dominant because it handles uncertainty better. Agile builds in short cycles, gets user feedback faster, and allows change before too much money is sunk into the wrong direction. The slides explicitly describe agile as dominant because of speed and flexibility. This does not mean agile is chaotic. It means controlled iteration usually beats slow rigidity in fast-changing environments. :contentReference[oaicite:6]{index=6}

7) Prototypes and wireframes matter because they make requirements visible. A user can react much more effectively to a mock-up than to a long requirements document. Prototypes show actual data in context, let users test interfaces early, and improve communication between users and developers. But they can also mislead if users think the mock-up is more finished than it really is. :contentReference[oaicite:7]{index=7}

8) AI will not eliminate the need to understand programming logic. The chapter argues the opposite: more people will generate code, so more people need to understand how code works, where it can fail, and how it can introduce security flaws. AI copilots can be useful, but they can also produce bad code that looks convincing. That means managerial and user judgment matters even more, not less. :contentReference[oaicite:8]{index=8}

9) LCNC tools are useful, but dangerous when they bypass governance. Low code/no code can help small teams, prototyping, dashboards, and time-sensitive internal tools. But the slides emphasize serious concerns: bad data, duplicate systems, legal violations, abandoned platforms, and security holes. The key lesson is not “never use LCNC,” but “use the right tool for the right job, with oversight.” :contentReference[oaicite:9]{index=9}

10) Most software project failures are managerial as much as technical. The slide deck lists poor goal setting, weak leadership, lack of executive commitment, poor resource planning, scope creep, weak communication, bad technical choices, poor testing, and political conflict. These are management failures as much as engineering failures. That is why future managers cannot treat IT projects as something “the tech people” handle alone. :contentReference[oaicite:10]{index=10} :contentReference[oaicite:11]{index=11}

11) HealthCare.gov is the case study for what happens when governance collapses. The launch failed because of unclear authority, weak planning, poor testing, low scalability, bad UX, and poor measurement. The rescue worked because experienced leadership, strong coordination, stand-up meetings, and technologist involvement were finally brought in. The case is not just about government; it is about what large project failure looks like anywhere. :contentReference[oaicite:12]{index=12} :contentReference[oaicite:13]{index=13}

Make, buy, or rent decision factors

Programming tools and concepts

Waterfall vs. Agile quick breakdown

Scrum essentials

Why technology projects fail

5-question advanced multiple-choice quiz

References / citations

1. Course slides: “Software Project Management,” MIS 301 Information Technology Management, University of Texas at Austin McCombs School of Business, including slides on user responsibility for requirements, systems development, development challenges, the project management triple constraint, dealing with uncertainty, writing software, compilation vs. interpretation, agile vs. waterfall, prototypes and wireframes, AI and programming, low code/no code, project failure causes, and HealthCare.gov failure and rescue. :contentReference[oaicite:14]{index=14} :contentReference[oaicite:15]{index=15}
2. Textbook Chapter 10: Used for make/buy/rent decision factors, programming tools and languages, Java and scripting, AI code generation, LCNC risks and uses, SDLC, waterfall, agile, scrum, TCO, project failure causes, CMMI, and the broader analysis of the HealthCare.gov case.