Pass Your Isaca CISA Certification Easy!

Prepare with top-notch Isaca CISA certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All Isaca CISA certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Lesson 2

6. Outsourcing and Globalization

Let's now talk a little bit about outsourcing and globalization. Many, many companies outsource for a variety of reasons. It's cheaper, or they can have a shop that's running at night while this side of the world is sleeping. That side of the world is busy working. Maybe they just want to have a local presence. Or maybe they just want to be able to not worry about a whole section of its service and let somebody else handle it. Maybe the call centre is outsourced. The Help Desk is outsourced. Disaster recovery is outsourced. Certain consulting is outsourced. Get consultants. So let's talk about different kinds of outsourcing resource practises with in-sourced resources. That of course means that we're getting people from our own organization, and we're picking different people, possibly from different departments or our own department, to work on a project. Outsourcing, of course, means that we are having some other organization, a third party, do stuff for us. We could have a combination of both. It could be onsite or offsite. And offsite doesn't necessarily mean in a whole other country, but it's not at our headquarters. It could be at another location. But then, of course, we can also have offshore, which generally means a whole other country, which has a whole other set of regulations and culture and language and time zones and things like that. And when we're involving all of these, then we have this concept of globalization. Outsourcing help with desktop application development or disaster recovery is now very common in terms of strategy and outsourcing. It's also very common to outsource some of your highly skilled tasks. It's common to outsource training. So these are just some things. If you need really highly skilled people to design or develop something, you could outsource that. So these are different possible areas in which we'll outsource, and we need a strategy for dealing with the outsourcing. And if we're going to have a global strategy, then we're taking advantage of offshore and offsite resources and outsourcing. But of course, management's got to pay close attention because you've got to—I mean, they're outside of your control, especially if they're in another country. So you've got to make sure that they're doing what you need them to do and not getting you into any kind of trouble or costing you unnecessarily. So the big question then is, if we're going to outsource, do we get a return on investment (ROI)?And there's a little formula here that you do not need to memorize, but you can see the return on investment. We take the revenue that we take in minus the expenses, and we divide it by the investment. And that whole thing multiplied by 100 tells us our return on investment. If we're going to be contracting people, contractual agreements have to include the ability to review and audit. And I'll tell you a good contractor that's going to do stuff for you. They should be willing to show you at least the relevant parts of their own security policies, so that you know there are no gaps. Maybe you've got all your security covered, but maybe they're really lax and you're depending on them for certain core functions. So they should be willing to show you their security policy and their disaster recovery and business continuity plans as well. So you need to be able to review and audit the contractual agreements. You need to be able to have a certain expectation of quality of service and continuity of service. and you want to see the controls and the procedures that they have in place. Here's an example of a service level agreement in SLA. So we can see that we have parties to an agreement; we expect certain performance levels; certain services are being provided. Here are the penalties in case you don't like them. Here's this thing. Each downtime violation will result in a 5% reduction fee for the month. Here are the disaster responsibilities. And so we expect to have all of this stuff built into the SLA. Along with that, you're probably going to have them sign an NDA as well—a nondisclosure agreement where basically we're entrusting them with sensitive information, confidential information, or corporate confidential information. So we want them to sign an NDA where they won't reveal this stuff. So we want to see the NDA and make sure people have signed it. And the NDA can be for one party, for their employees, mutually restrictive between both of us, for just specific people on the job, whatever. But it is a legal contract outlining what we're sharing, how we restrict access to third parties, and the confidential relationship to protect our information assets. Like, I've been at sites where we signed an NDA, and they still didn't trust us. So we did get issued laptops, but the laptops were locked down in a way that there was no way to take information off of them, there was no way to email it out, and there was no way to plug in any kind of removable media at all. And they had lots of tight controls over information leakage outside of their own organization. And the badges that the contractors wore had distinguishing features on them. So everyone knew at a glance that we were not an internal part of the organization; we were contractors. So contract management practises have to be clear; there have got to be clauses to guard against potential losses and situations. There's got to be procedures for protecting the organization; there's got to be nondisclosure; there's got to be understandable reporting. We expect the format and the procedure for reporting to be understandable. We expect a comprehensive access control policy. We expect formal change management to be in place. So if you're going to change anything at all, we expect a formal process to be in place where it's approved. You don't just change or add anything ad hoc go changing or adding anything.and if there's going to be any third-party outsourcing. If they're going to outsource, we need to address all of that as well. So now how do we audit and report on third parties? We have to worry about that as well. Make sure that that is built in so that when you are looking at its contracting strategies and policies, make sure, of course, that management supports the development of these service contracts. And, prior to the agreement, you must review all contracts to ensure that they are appropriate and cover all of the terms you require. You may need to look at their documented procedures. Whoever your outsourcer is, make sure that they have some sort of quality assurance program, and make sure that their quality assurance programme actually produces results. And you'll need to regularly review the contracts, the SLAs, and the NDAs.

7. IT Performance

The last topic of this lesson is its performance. Let's talk about it. Performance and the idea that we need to be able to monitor, measure, and create performance indicators And we need to see how our performance is working and whether or not we need to upgrade or improve what we do to improve our performance. We establish accountability, and we have to actually look at data. It's so easy to assume that you're doing things a certain way, that you're at a certain level of accomplishment or performance, but you've got to look at the data. The data has got to support it; I see so many people making it, and I've made the same mistake myself. You think you're at a certain level; you think, "Oh, we're doing terribly" or "Oh, we're doing really well." But until you actually look at the data, you don't really know. So you have to look at the data. Decisions have to be data-driven, which means you have to collect data properly. So when we're looking at performance, we want to actually get that data, analyse it, and see: Did we really sell? Are we really at something? Did it really cost this, or did it not cost that? And how much did we really make? And how much did we really improve our process? And we need to, of course, document and report the results. So we have different approaches here. You'll want to have technical metrics wherever possible. You want to provide actual quantitative data, stuff that you can actually say and actually measure. We can measure the many occurrences. We can measure this much time out, this much downtime, or when I was working in health informatics. This many new cases of infection can be counted. We can measure this many ups that went down. We can measure this much medicine, this much data, and this many reports. So you want hard, quantifiable measurements and some examples. How many vulnerabilities do we have? What are our audit statistics? How many unresolved security issues do we have? And you could go on and on. How many unpatched systems were down, and how many times did something go down? How often were there security breaches? So it has to be hard, quantifiable data. So then we have this concept called KPI and KGI KPI: a key performance indicator tells us how well we're doing. The KGI, the key goal indicator, is what are we trying to achieve? And remember how we looked at that balanced scorecard and there was a target? The target was to have no more than X number of incidents, but the reality was this. So therefore we were either red, yellow, or green, or red, amber, or green. And so we have the target, the key goal indicator; we have the KPI, the key performance indicator; and then we can tell how well we are actually doing here. So, like, for example, our key goal indicator is 99% uptime, but the KPI shows we're only at 95%, so therefore we're perhaps at Amber, or we're only at 75%, so therefore, perhaps we're at Red. And so don't mistake the KPI with the KGI. The KGI, the goal, is the target. The KPI, the performance indicator, is: where are we really? How well are we meeting the goal? We already know that Six Sigma is a standard of quality improvement. We're trying to remove errors throughout our whole business process. We're trying to minimise the variability in our business process and manufacturing process. So whenever we are trying to improve processes and we're monitoring performance, we have to look at the data and figure out, "Okay, how can we improve this?" And so Six Sigma says that we'll have a formal process to reduce errors. And we'll have a standard way of making sure that there's no variability in our process. ISO 9000 is a published standard for quality management, too. And you can be ISO 9001 certified.So when you're reviewing performance monitoring and assurance practices, look for things like, "Okay, what is their capability or maturity model?" Do they have control objectives implemented for It implemented?Let me see your KGIS and KPIs. Are you using something like Six Sigma or ISO 9001? Are you actually using an actual procedure for improving processes? And can I see your balance scorecards too? And are you even aware of your balance scorecards? So those are the things we can do when we're looking at its governance. And with that, that is the end of lesson two. We're now going to get on to the next lesson and talk about system and software development lifecycles.

Lesson 3

1. System And Infrastructure

As you go from one release to another, invariably at some point you're going to have to deal with data conversion. I mean, one project we worked on once lasted a year because earlier versions of the product were used, and we had partners who simply refused to upgrade. and they wouldn't upgrade. They had millions of records, and they were worried because an earlier version was based on the sequel 2005, and the new release was going to be based on the sequel 2008. And the two schemas of the products were completely different. We had evolved the product so much that we included security features and all sorts of new reports and all kinds of stuff that wasn't in the old version. And so the partner, which had this deployment just all over the country, didn't want to upgrade until we could prove that their data would not be damaged in the upgrade process. So we spent a year making sure that this was the case. Because what you had to do was just laboriously go field by field. OK, this may be fixed-length characters and this is now variable-length, or it's a different length, or it's one kind of number to another kind of number. Perhaps this had a decimal point here and that now has a decimal point there. Or maybe there is absolutely nothing original to go to now. Or maybe the way the data was organised is totally different from this way. So we spent a lot of time mapping exactly what would happen to all these data fields and testing it. We actually took some of their production data into a test environment—just a copy to prove it. And then we had to laboriously go through and make sure that all the results were exactly what they should be and that they came out in reports the same way, too. So data conversion is very often not at all trivial. I mean, it can be a big deal. You can go from a system that's generally simpler or organised differently to a system that will be much more complex, probably organised more efficiently, or more organised with just a lot more going on—a lot more interdependencies and connections, whatever. So you're going to have to spend time on data conversion, and if you don't spend that time, yeah, you'll upgrade and the data will all convert, but then it's not at all what it should be, and that may not even show up until you do much more complex types of reports. So as an auditor, we have to consider that sufficient time was spent. And don't be surprised if you spend a year or a year and a half between major releases figuring out how to make sure that the data converts properly, especially in something as complex as what we were doing with healthcare. So don't be surprised that people have to spend that time and make sure that they did spend that time, make sure that they had controls in place, and make sure that they absolutely verified that there was nothing wrong with the data once the version was upgraded. So with data conversion, you're going to change computer data from one format to another so that an old programme's data can work in a new programme or in a new operating system or on a new platform. And examples could be as simple as character sets or types of numbers, or they could be as complex as things arranged totally differently. And there's nothing that matches from the older version to the newer version. It could also be different types of media. Well, we used to store these all as WMVS; now we're going to store them as movies. And how do we convert the data without losing image quality? Because whenever you transcode something, you always lose something. So you have to really take a look at all of that. It could also be an MS Office format. We're going from DOC to DOCX, or we're going from a proprietary thing like Microsoft to an open source thing; that's an application that's going to use proprietary data. Or maybe we're going to run virtual machines and we have old VHDs; we now need to convert them to VHDXs, VMDKs, or whatever the format is. So, data conversion could be all kinds of things. But as an IS auditor, we need to know for sure that when they planned their data conversion, they had all the controls in place and did all the testing to know for a fact that the data came out clean. In our case in the EHR, we had a lot of data that had duplicates; therefore, it was dirty data, and we had to find ways of getting rid of the duplicates because it was going to corrupt our new system and our new reporting. So be conscious of all of those data conversion techniques. There are a variety of ways to do it. You can have two systems in parallel. So, like, I've got the old system and I've got the new system. We run them together in parallel and slowly phase out the old system while we phase in the new. That's one way. Another option is to phase it in like modules. So we'll gradually phase in one whole functionality or module at a time. Or you just flip the switch, and you're ready to cut over. No matter what method you use, you've got to make sure that you can fall back in case the whole thing is a failure and that you haven't ruined your data while you do this. So make sure the data is very well backed up and very well documented. As you migrate applications or as you migrate data, you'll want to have a solid migration plan. Here's sort of a diagram of the several systems that were undergoing migration releases. Whatever it is, your migration plan should show a breakdown of activities when we're doing it, what's going to be impacted, how we fall back in case we have to, who's going to be involved, and who's potentially going to be impacted, because you're trying to bring the whole system online without disrupting anybody or really causing any interruption. And so sometimes folks will deploy something on the weekend when no one's in, or we do it at night, or we do it in small phases, or we do it in small parts of small geographical areas or departments, so that we can learn lessons and do it even better and more effectively as we continue to phase out the old and phase in the new. So, when you're evaluating the effectiveness of a system migration as an IS auditor, you should bear in mind the following things. Make sure that the right questions were addressed early on, which means people had to ask the questions, which means you need to involve all kinds of stakeholders so that the questions are raised. Make sure that the requirements and expectations are set. People know what to expect. They are not expecting a miracle or for it to do this or that. Make sure that there is proper support in place so that the people who are rolling it out and the users have support and training, and they have people right there to help them. Make sure that you have support structures and support functions. Train the end users. You want them to be self-sufficient; give them ways of resolving their own problems, requesting helpdesk support, or escalating problems. Make sure you have all of that in place and that you figure it out. Exactly. which means you need to know all the scenarios. And again, you need to get the input of all the people who are going to be involved and who know what will happen. And then you, of course, perform the data conversion, and you monitor how well and how effective it was. And then hopefully the data has been converted with only a little bit of cleanup, which almost certainly will be clean up.And then the client can move on with this new application that will help them do their business functions a whole lot better. And with that, that is lesson three. We have talked about the software and system development lifecycle from planning and requirements gathering through design and development, testing and change management, and release management. The next thing we're going to talk about in the next lesson is maintaining this software or system development lifecycle.

2. Requirements

I can't stress enough the need for proper requirement gathering and how you should have a team of analysts working on gathering requirements. You know, in all honesty, in larger organizations, analysts should actually learn at least this much coding so they understand what it is that application developers really need and how to write a use case. They understand what black-and-white requirements the application developer needs. And an application developer, even though they tend to not naturally have the personality for it, should learn to interact a little bit or at least understand how a business analyst works and how they have to work with a customer who has only the vaguest notions of, "Oh, we kind of like this," and they don't even have the first schools. That's really what they want. So when you're gathering requirements, you've got to make sure that you're not interested in having them say, "Well, we want a kiosk that we can walk in and use in the lobby instead." What are they trying to solve? You're less interested in hearing their solution, although you do want to hear the solution because they may have figured it out. But generally, the customers are the clients, and usually they're within your own company; they're just another department or unit. Generally, they're trying to solve a problem. And the problem could simply be, well, that we simply need to be able to move the lines of customers past our desk faster. When people come in to apply for a loan or something, maybe we need something that helps automate that process, and they might come up with solutions already. But what you're really trying to hear is, "Okay, you get a backlog of customers who are trying to go through an application process; you need something to help that." So maybe a very simple self-service thing All right, well, when they go through the application process, what are the bottlenecks? and so you really need to talk to them. Oh, the bottleneck is just the preapproval of whether or not they even qualify for this loan or something. And so then you go, "Okay, well, let's see if that's really the preapproval process that's the bottleneck here. Then can we develop something that helps the customers go through a preapproval?" And if they're not pre-approved, then we divert them to some other sort of customer service. Meanwhile, who is alerted to this? And then different people will say, well, I don't want to lose track of these folks. I want to offer them other services. If they're not approved automatically for this kind of loan, we can still offer them those kinds of things. And then somebody else will say, "Well, I want to make sure that when they walk in, there's not a huge crowd of people milling around waiting because they'll get bored and they'll run across the street to the competitor." So you want to hear people's pain points when you're gathering requirements rather than their immediate solution, because the immediate solution may not actually be what it is that they need. They may be thinking that they want a kiosk, a programme, a website, or something else, but that may not really address what they need. And then, of course, upper management or management, or whoever the sponsor is, is going to have the final say, and they're going to say, "Yes, we do need this, but all of those little wish lists want features we can't afford or that are beyond the scope of this." And finally, the management will decide what really goes into this project. So when you're gathering requirements, you need to know how the end user is going to interact with this system because they're the ones who are going to implement it, and they're the ones who are going to adapt to it or need to. So how will they interact with this thing? What are the conditions that this thing will operate in? Like, even when I was in Africa, we had a situation where we had to get these little computer systems out in the bush, and some of these sites are off the electric grid, right? How do you get a computer system to a health facility that doesn't have power? Well, now we're looking at solar power, and we're looking at solar panels that are just like coffee cups, but with a rubber sort of backing so that you can put coffee cups on them. So we understood the environment. It was harsh. People will be untrained to deal with those kinds of technologies. The panel, the solar panel, is just a rubber thing that opens up, and it has to directly feed the little network that we're going to give them. So I mean, you need to understand the environment itself, or understand that maybe in that location there's no internet access, or in that particular location, when you roll out computers, don't put a virtual machine on it because they have enough trouble understanding a desktop. Don't give them to start menus. So you need to understand the environment in which users will use it and how they'll interact with it. One of the issues is that developers who are too busy creating solutions and are too focused on the latest technology may not understand the user's environment or situation. And the system analyst has to explain that we used to take developers with us out into the field in Africa so they could see for themselves the level of the user. Users can't even find the spacebar. So don't give them that kind of thing, like a virtual machine. So you really need to understand this, and I can't stress it enough: the success of a project will depend upon how well we gather requirements and translate those requirements into a solid design that the developers can really understand and sink their teeth into. So we need to understand, of course, the conditions, how the users will interact, and any criteria that the system is going to need to meet. So when we're looking at the requirements definition process, here's a good little checklist here.Identify the stakeholders. Stakeholders are not just management; they also include all the people who are going to use this thing. analyse the requirements to locate and fix any conflicts, and identify the boundaries of the system. Ideally, how will this thing interact with the whole environment? Convert user requirements into actual system requirements; record the requirements in a formalised structure. And so, like for developers, often you'll write use cases for them, probably write use cases for them, and then verify that the requirements are totally complete. They're verifiable; you can change them; you can test them; they're consistent. If there are any conflicts between stakeholders, which there will be because people will have all kinds of wish lists and they'll want all kinds of features that aren't realistic, then resolve the conflicts. Usually upper management or the project sponsor says no, folks, but this will ultimately be what we have. And then it's up to management to work with people to help adapt to this new solution, whatever it is. When we are looking at requirements, when we are analysing the requirements, and when we are managing the requirements, we need to make sure that this requirement understands the constraints of this organization. Like, you know, I've been in situations where the organisation had all the money in the world and then had no money. And so what are the constraints and organization? They had all the money and huge amounts of technical expertise and highly technical consultants that they could pull in, as opposed to no money whatsoever. They were surviving on donor funds and everybodywas overworked because hardly anybody had any training. So you need to understand what the constraints of the organisation are, what the functionality of this thing will be, and what performance levels are required. So like in our case in Africa, well, they only need to fire this thing up for a couple of hours for data entry. And it doesn't need to be on 99.99% of the time. It needs to survive in a harsh environment as opposed to being fast. It just needs to be able to come on. They can do their data entry from paper andthen they can shut it off and it needsto survive heat and dust and moisture and rainsand all kinds of that sort of thing. And then also, what external system does it have to be compatible with? I mean, I've seen so many solutions that when you try to plug them into the larger picture, they're either duplicating work or they're a parallel system. People are now burdened because they have two data entry systems, and you must somehow combine the data, which there is no mechanism for. So how compatible are these solutions? And we obtain all this information by interviewing everybody: the customer, the use cases, and the wish list. We talk to everybody, including those who possibly could develop it. One thing that you'll do if you get an outside contractor is send out a request for proposal, or RFP, and in an RFP you're asking vendors or whatever organisation is creating this thing. Would you please propose your solution or product? If you send out RFPs, be sure to make sure that the RFP is not just the solution but includes things like the financial stability of the vendor, how available they will be to support the product, and not only during the installation but afterwards, how much you can interact with them during the development phase so that you can make sure that they're staying on track. Will the source code be available? What if that vendor goes out of business? I mean, I've certainly been in situations where even beforethe product was done, they went out of business. We need to have the source code in escrow so we can go grab it as part of our contract. We can have the source code and get someone else to finish it up. Or also, what is their contingency plan? What's the vendor's contingency plan if they can't meet your needs? I've been in situations where we had customers who completely didn't know what they wanted. They kept adding requirements as we went along. And we had to have a contingency plan for bringing in extra personnel and extra staff. And we had to have a clause in the contract stating that if you change the scope, Mr. Customer, we have to be able to renegotiate the price because now we've got to bring people in because you've got a deadline and because you couldn't estimate your deadline and you changed the scope after we signed the deal. If you require more from us than was originally planned, whether because you changed the scope, we must charge you for this. So you've got to make sure that all of this is in the RFP so that everything is covered and everything is clearly understood. One of the biggest project killers is when people assume that everything will be understood or that there will be no issues or conflicts as we get started. Don't assume anything. Have the contingencies written down in black and white. What do we expect and what happens in casethings go awry and make sure everybody understands upfrontso for determining the business case for this thing,this system, this solution, this application, as we areauditing this, let's take a look. When they created the business case for this, whateverthis is, this change, was this logged officially? I mean, was this actually logged? Was there a feasibility study? Was there an actual business case made? Were the benefits clearly defined and were the requirements clearly gathered and stated? Were they all collected in an accurate, measurable, and useful way? If there were any RFPs, what were theRFPs and were there RFPs from many suppliersso that we can compare them? Because of course, one thing you don't want is somebodykeep on giving the contract to a brother in laws. That's not necessarily a bad thing, but you want to make sure that enough vendors proposed their own solution so that there was a choice and that the choice was made in a fair and equitable manner that made business sense. So the IS auditor needs to be looking at all of these things in the requirements and early parts of a system or software development lifecycle.

3. Project Management Tools- Part1

As an IS auditor, you should understand some of the principles and a few tools involved in project management. And we even talked about earlier how the IS audit team will have a project manager manage the audit itself. So let's talk about project management and just a few of the tools that are very common in project management. When we talk about project management, we have to also look at project governance. And project Governance basically provides the ownershipand the oversight of the whole project. Who is in charge of this whole thing? Who's governing this project? And it won't just be the project manager, because often the project manager I'll tell you a story with project management. Project management, sometimes you're not in completecontrol of the people you're working with. You have to negotiate or coax people into cooperating with you. You have to coax department heads into loaning resources and people to you. and so often there's a negotiation process. You can't just tell people who you are. Sometimes you don't have direct control over the people who work with you. As a result, it can be difficult to keep things on track when you don't have direct authority over the people who work with you. So with project governance, we want to make sure that the project has oversight and ownership. We need to know who the stakeholders in this project are. Everyone from the project sponsor, the person who is paying for this thing, to the individuals who will be doing the data entry, running this thing, and using this thing. And the customers, if it involves externalcustomers or other kinds of customers, howtheir experience will be improved by this. It's all about improving people's experience and productivity. And so part of this is also going to be defining the relationships among all the stakeholders. You will find that stakeholders will be atodds and some will even be hostile toeach other or they'll have opposing needs. And I remember on one occasion, on one project, the project manager was just bemoaning; he was saying, "God, I wish I didn't have to constantly deal with competing interests." And that's just the reality of project management. You will have competing interests. And so that's why it's so important to make sure this is within scope. There is a project sponsor who is paying for this thing. There's ownership and governance that are ultimately going to say, "Folks, thanks for all your input, we're doing it this way." And you need to have a relationship with everybody here because, ultimately, you can't whip them into doing what you need. You need to work with them so that they give you the best performance as you're going through this whole thing. And you're going to also need to properly assign resources. Most project management tools allow you to actually specify who's working on what and for how long on what.So, you'll know if people are underutilised or if they're odor, over utilized.I mean, there have been plenty of times when I've seen, "Oh, so and so is 100% utilized, okay?" So you can see who is actually assigned to what. One of the difficulties is estimating. How long does it really take for somebody to do something? Because you can have three perfectly competent people to do a specific task, but one person is blazingly fast, another person is a lot slower, and the slower person is very accurate. Whereas for the blazingly fast person, you have to keep checking their work. So knowing how to estimate time, you can haveworked on in an industry for years and stillnot be very good at estimating time just becausethe variables, it takes so long to understand thevariables, and through no fault of your own. So with project governance, we need tobe able to control this project. The mechanisms for project governance, of course, are going to require senior management, and you need them behind you. You need them on board to basically say, Folks, this is how it's going to be. Then there's also the management of the users. You'll have the project steering committee; you'll have the project sponsor, the person who is paying for this CIO or whatever executive it is. You'll also have the team that actually develops the system or the application. You'll have a project manager who basically project manager'sjob is to just keep it all on trackand on budget as best as possible, making surethat the resources are utilised effectively. You'll have the development project team; you'll have the user project team. You'll have the IS officer, and you'll have a security officer who should be involved every step of the way to make sure that security risks are always mitigated, dealt with, and accounted for and not introduced or ignored. I have to tell you, with software development, it's almost always quick; we've got to get it out, we've got to get it to market, we promise this, and we've got to get it in production. And the developers are simply too busy trying to make it work to test to set whatever parameters will limit buffer overflows, to check for this, or to remove any back doors they've created. And so you need the information security officer to always be involved to make sure that nobody's forgetting anything or overlooking anything. And then, of course, quality assurance. Every step of the way, the quality assurance team ensures that we are adhering to whatever our procedure or specification is to ensure that we have quality assurance from beginning to end. Now let's take a look, just really quickly, at some common project management practises and tools. The first thing is, of course, that we have to deal with the budget—what will it cost—so you must maintain and manage that budget. You have to schedule resources, establish your time frame, and establish your schedule. I can't tell you how many times, in fact, in large organizations, you'll be surprised to learn that most projects fail to meet their objectives. Most projects run overtime and over budget, and actually, most projects fail to be quite honest. However, I want to tell you the secret. Here is the secret of project management. The project was successful. If the client thinks so, you can put something out where everyone's going, "Oh, that is the worst thing." Oh, we lost so much. We had all these negative things happen. But there's all this hype, and the client is pleased. If the client is pleased, you're successful. That's the bottom line. If the person paying for it is unhappy, it doesn't matter how fantastic the product is, how well you did it, how cheaply and quickly you did it; if they're unhappy, you didn't succeed. So the success of project management is that the project is successful when the client thinks it's successful. And that really is the bottom line of project management success. So let's take a look at some methodologies. Let's look at CPM, or critical path methodology. Let's take a look at Gantt charts and perk charts. Just a quick overview so you understand, in general, what they do and how they work. There are whole classes and whole tools on how to create and use these things, and there are free ones as well as paid versions. And let's talk a little bit about time box management. This is a sort of typical example of critical path methodology, or CPM. And you're interested in major activities and how long it will take to complete major activities. And CPM is based on the concept of the longest pathway of activities. Now, some projects are just we do one thing,then we do the next, then we do thenext, then we do the next and we're done. But for others, we do one thing. When that's done, we can branch off and do two more things and another thing. As a result, you have several branches and paths running concurrently. In the CPM method, we're identifying all of these things that we're trying to do, these activities and pathways. The pathway that takes the longest total time is called the critical path. There are other sorts of side activities that are going on that may take less time. If you have a group of side activities that go like this and this is the longest, this becomes the critical path. And it's all about managing the critical path and figuring out what is causing a drag or a delay on this project. So if we analyse this a little bit here, we start with Activity A. and all of these activities are listed like ABC. And you can see several pathways in this; we're showing the time to complete each activity as well as the dependencies. Like after we're done with A, which will take ten days. And then usually, with CPM, you show the earliest start and finish times and the latest start and finish times. So the earliest and the latest for the very first activity will be the same thing.So Activity A has a duration of ten days. The earliest is start on day one, the latest is starton day one, the earliest to start on day one, finishearliest and latest on day ten when that's done. And so this thing adds length to the project, or a drag of ten days. Once activity A is done, we can move to activity B, but we can also start on activities F and H. Now, activity B is a 20-day activity, and usually in the critical path, you don't have any spare time to mess around. So the earliest and latest we can start and finishis day eleven and day 30 and it's 20 days. But for activity F, Because when you add F and G together, And F and G when we finish F and G for the entire project. For the final rollout. Post implementation. Whatever. The thing is, We have to have all three paths come together before we can start the final thing. So, like, maybe this critical path is the development of the software, while this path on top is preparing the infrastructure, and the path on the bottom is educating users. These are just examples. So by the time we're ready to actually roll out, activities E, G, D, and H all have to be done. Notice here that we've got this concept A TF," the total float. The float is the amount of spare time you have to get started later. So, for example, if going along this path of all these activities has a total of ten plus 20, plus five plus ten plus 20 days, and it adds up to something, but if you go along this path, it's only 15 and five days, so you've got a spare amount of time, a float of 15 days. So for activity F, you can start right on the next day, day eleven, or you've got 15 whole days before you can start. So with CPM, we know how much slack time we have and how much spare time we have before we've got to keep going. If we take too long, then maybe one of these alternate activities now becomes a critical path because it has the longest drag on the entire project. So this is the concept of critical path methodology. The next thing we're going to look at is Gantt and Perch charts.

ExamCollection provides the complete prep materials in vce files format which include Isaca CISA certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to Isaca CISA certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.