Latest / VoraPrep Audio — Professional Licensure & Certification Exam Prep / [CISA] CISA3: Auditing SDLC Project Management: Waterfall vs. Agile
Transcript
- Hey, welcome to VoraPrep Audio. Glad you could tune in. I want you to think about a project you’ve seen go off the rails. Maybe it was at your company. I’m thinking of a story about a huge bank trying to launch a new mobile app. They spent a year and millions of dollars building it, following a super rigid, traditional plan where everything was decided on day one. But then, a competitor launched an app with biometric login—you know, using your fingerprint or face to sign in. Suddenly, the bank’s app looked ancient. But their project plan was so inflexible, they couldn't just add the new feature. It would mean starting over. So, they scrapped the whole thing. Millions of dollars, gone. That’s why understanding project management methodologies is so critical for an Information Systems auditor. Your job is to look at a project, understand the approach they chose—whether it's rigid or flexible—and see if the right controls are in place to stop that kind of disaster from happening. Let's start with that traditional, rigid approach. It’s called the Waterfall model. The name tells you everything you need to know. It’s a linear, sequential process. Each phase has to be one hundred percent complete before the next one can begin, just like water flowing down a series of falls. You can't go back up. Think of it like building a skyscraper. You have to finish the foundation before you put up the first floor. You have to finish the first floor before you start the second. You can’t start framing the windows on the tenth floor if the ninth floor doesn't even exist yet. It's all about structure, detailed upfront planning, and tons of documentation. So, the first phase is Requirements. This is where everyone gets in a room and documents every single thing the system needs to do. As an auditor, you're looking for two things: are the requirements complete, and did the business stakeholders actually approve them? A sign-off is your evidence. Once that's locked down, you move to Design. Architects create the blueprints for the system based on those approved requirements. Here, you're looking for evidence of design reviews. You’re checking to see if the design lines up with the company's security policies. Next comes Implementation. This is the actual coding. The developers get to work. Your audit focus here is on control. Are developers following secure coding standards? And critically, do they only have access to the development environment, not the live production system? After the code is written, it’s time for Testing. This isn't just one thing; it's unit testing, integration testing, the whole nine yards. But the big one for you as an auditor is User Acceptance Testing, or UAT. This is where the actual business users—the people who will use the system every day—get their hands on it and confirm it does what they need it to do. You need to see documented test plans, the results, and a formal sign-off from those users. That UAT sign-off is your last real safety net. Then you have Deployment, where the finished product goes live. You’ll be reviewing change management records to make sure it was a controlled, authorized release. And finally, Maintenance, which is all about ongoing support and bug fixes, governed by your normal operational controls. The beauty of Waterfall for an auditor is that it's easy to follow. The phases are distinct, and those formal sign-offs at each "phase-gate" give you a perfect paper trail. The weakness? It's rigid. A mistake found late in the game is incredibly expensive to fix. You have to go all the way back up the waterfall. Now, what if your project is more uncertain? What if you don't know all the requirements upfront? That’s where Agile comes in. Agile is an iterative approach. Instead of one massive, long-term plan, you work in small, incremental chunks. The whole philosophy is captured in something called the Agile Manifesto. It has four core values. One is valuing "individuals and interactions over processes and tools." This doesn't mean you ditch your tools; it just means recognizing that smart people collaborating is more effective than a rigid process nobody follows. Another is valuing "working software over comprehensive documentation." Again, not zero documentation, but the primary measure of progress is a product that actually works, not a 300-page manual for a product that doesn't exist yet. It also prioritizes "customer collaboration over contract negotiation" and "responding to change over following a plan." The whole point is to be able to adapt. Remember that bank? An Agile project could have incorporated biometric login into the next short development cycle. So what does this mean for you, the auditor? Your evidence just looks different. Instead of that giant design document, you might be reviewing a series of well-defined "user stories" in a tool like Jira. How do you find evidence of customer collaboration? You could look at attendance logs for review meetings, or see how customer feedback directly led to changes in the project's to-do list, which is called the product backlog. The most popular way to *do* Agile is a framework called Scrum. You’ll see this a lot. A simple way to remember its core parts is the mnemonic 3-5-3. It starts with 3 Roles. You have the Product Owner, who is the voice of the customer. They decide what features are most valuable and in what order. Then there's the Scrum Master. This person is not a project manager; they're a coach, a facilitator who helps the team follow the process and removes any roadblocks. Finally, you have the Development Team, the group of people who actually build the product. Then there are 5 Events, or ceremonies. The whole process happens in a short, time-boxed cycle called The Sprint, usually a month or less. Each Sprint starts with Sprint Planning, where the team decides what they can accomplish. There's a Daily Scrum, a quick 15-minute sync-up meeting. At the end of the sprint, you have a Sprint Review, where the team demos the working software to stakeholders. This is a huge control point. Finally, there’s the Sprint Retrospective, where the team discusses what went well and what didn't, so they can improve in the next sprint. That’s a key process improvement control. And finally, the 3 Artifacts. You have the Product Backlog, which is the master list of everything the product needs. The Sprint Backlog is the subset of items the team commits to finishing in the current sprint. And the Increment is the usable piece of working software created by the end of the sprint. So, 3 roles, 5 events, 3 artifacts. That's your Scrum 3-5-3. Okay, let's put this into practice with a CISA-style question. The exam will give you a scenario and ask you to spot the biggest risk. Here’s a four-step way to break it down. First, identify the methodology. Keywords like "sequential" or "fixed requirements" mean Waterfall. "Iterative" or "sprints" mean Agile. Second, pinpoint the audit objective. Is the question about governance, risk, change control? The question will tell you what to focus on. Third, map that objective to the right controls for that methodology. For Waterfall, you're looking for sign-offs. For Agile, you're looking for a healthy process—like an empowered Product Owner or good sprint reviews. Finally, select the answer that points to the greatest risk. A failure in governance is almost always a bigger deal than a small process mistake. Let’s walk through an example. An auditor is reviewing a project to replace a loan system. It's over budget and behind schedule. The team says they're using Scrum. First, the auditor checks governance. They ask for the project charter. They find one, but it was never formally approved. Big red flag. They also find out the Product Owner is an IT manager, not someone from the business lending division. That's a huge problem. The person responsible for defining value doesn't even represent the customer. Next, the auditor observes the team's process. The "Daily Scrum" meeting is 45 minutes long, with a manager grilling each developer. That's not a sync-up; it's a status report. They also learn the Sprint Retrospectives—the improvement meetings—have been cancelled for months to "save time." Then, they look at the Product Backlog. They see that executives are just emailing developers directly with "urgent" requests, bypassing the Product Owner and disrupting the sprint. This is classic scope creep. So, what's the auditor's main recommendation? The project isn't failing because Agile is bad. It's failing because of a terrible implementation. The root cause is a complete failure of governance. A tempting wrong answer on the exam might be "recommend more Scrum training for developers." And yeah, they need it. But that's a secondary issue. The primary recommendation has to be fixing the governance: appoint a real business Product Owner and get a formal, approved charter. You have to fix the foundation before you can fix the process. A lot of people think Agile's flexibility means it has no controls. That's a dangerous misunderstanding. Agile doesn't mean chaos. It relies on disciplined practices. You should still find clear audit trails, like well-managed backlogs, version control for all code, automated test results, and clear definitions of what "done" means. If those things are missing, it’s not Agile. It’s just a poorly run project. So on exam day, when you get a question about this, first figure out if you're in a Waterfall world or an Agile world. If it's Waterfall, look for weaknesses in the formal sign-offs and change control. If it's Agile, look for breakdowns in the Scrum roles and events, like a Product Owner who has no power or stakeholders who never show up to the Sprint Reviews to give feedback. The core idea is this: Waterfall is best for stable projects where you know exactly what you need upfront. Agile is built for a world where requirements are likely to change. But no matter which one you choose, fundamental controls for governance, risk, and change management must be there. Your job as an auditor is to find the evidence that they are. If you're working through this and want to test yourself on CISA-style questions about Waterfall, Agile, and dozens of other topics, check out the VoraPrep app. It’s a full exam-prep system with lessons, thousands of practice questions, and even an AI tutor to help you break down the answers. You can get started at Vora Prep dot com. It's free to try. Alright, that's our time for today. Keep this framework in mind as you study. You're not just memorizing terms; you're learning to see how a project really works—or why it's failing. You've got this. Talk to you next time.