Lesson 3

4. Project Management Tools- Part2

Well, we looked at critical path CPM, andthat's how we can sort of keep track.Like, maybe people say, well, we don'tknow if we can start that immediately.That's okay because we've got afloat, we've got some slack time.Let's now take a look at Gantt and perk charts.Very, very common project management tools.Here's an example of a Gantt chart.It's actually a really simple example.This shows our project schedule at a glance.And you have something calleda work breakdown structure.And so you might have this collection of activities.So we have this work breakdown structure w BS one.And then we can have, like, the totalview of all of the activities inside.So the summary of number oneis created by activity ABCD, okay? And so we can see here that this entire thing will take from week one up to week whatever it is, week ten or week fifteen or whatever.And the nice thing about this is that it often uses shading to tell us how much is actually done.So I can see here that the black part is we're that much done, so we're 57% complete.I've got activity A, which is 67% complete.I've got activity B, which is 50% complete, and activity D, which has not And you can just look down at the breakout, the pert chart here. And pert charts are used a lot with CPM. This is done a little differently. It looks kind of like a CPM, doesn't it? But it's not exactly the same.These points like 10, 20, 30 theseare actually milestones, they're not activities.So they're like starting points or ending points.When you do them, you usuallyjust increment them by tens.So point number 1020, 30, 40.And then that allows you to slip in15 or 16 if you need to.And so when I see my starting point of the wholething, starting point number ten, I then see two activities.The activities are marked by arrows,so the activity is an arrow.So down here I have activityA, which will take three months.And when you estimate the time or yougrant amount of time you can either have,this is the most likely time, the mostoptimistic, or the most pessimistic amount of time.And so activity A will take three monthsand get us to milestone number 30.And milestone number 30 could be an endingpoint and a starting point for something else.These accomplishments, these events, these numbers here,which they call them events, they don'tactually take up any resources or time.They're just a point that wereach or that we start from.And so starting with starting point number ten, three monthson activity A, four months on activity B, it'll getus to points 20 and 30 when we hit 00:30branches out to two new activities, activity D and E.Activity D would take a month.Activity E will take three months.When D is done, we get to 00:40and then we can start another one.When all of these are done, we'refinally at some kind of finished point.We're at 00:50 here.So this is the idea of the pert chart.We have these sequentially numbered events whichare basically starting and stopping milestone points.And we can see that the events arelinked by arrows that represent activities with time.And we can't start a new activityuntil we finish the previous activity.You can see from looking at all of these things thatyou really need to plot out from every single step what'sit going to take to get from here to here.And that's part of thewhole project management process.Not just kind of like kind of like glossing itover, what actually does it actually take to the day,to the hour, if it takes to write this document,if we know that it takes X amount of time,pad it if you've got the time or put inmore resources, don't ever go always on the most optimistic.One thing as a project manager you're going torun into is the customer is always going tobe like, well, hurry up, what's taking so long? Why is it costing more? And part of your job is going to be to set an expectation so that they understand. And what you don't want to do is just kind of always give them the most optimistic thing and then we run into trouble later. You don't want to do that if it's going to take this amount of time. You want to estimate it properly. If you frankly don't know, then try to do some little trial to kind of test. But I got to tell you, if you just say,okay, if we have to write a hundred pages of documentation and I know it takes me 1 hour towrite a single page, therefore this is a 100 hour project. You're going to do a trial that's too small, you're not going to realise that the writing alone took an hour, but it took 3 hours of research and 5 hours of interviews. And so you've got to think of everything that goes into these things. Did they think about all this stuff? How experienced was the project manager? How willing and cooperative were the client and the customer? How willing and cooperative were all the users? How were all the conflicts resolved? How willing and cooperative was upper management tojust help bring everyone into line and say,no folks, it's going to be like this.These are all the things we're going to look atwhen we look at, well, why did this thing fail? Or what's wrong with their process? What's wrong with their process is that it's always under budgeted, underfunded, and people want a lot more than what they're willing to pay for.And then they find out that there are all kinds of issues and staff tried to hide the issues.For example, I've seen situations where the client said, "Okay, we need a series of instructional videos created, and here's the budget," and so they hire a production team and a project manager. No, the reality is that it takes forever 1 minute to produce, and it takes two to three minutes to actually do the production, so you have clients with very unrealistic expectations, not to mention the fact that you didn't give them enough budget.And when they set up, the environment was too noisy. There was a train a block away, and I was constantly making noise. How many lines of code is this? Well, this thing has thousands or hundreds of thousands of lines of code.And so, when we're looking, we're trying to estimate complexity.There's something called function point analysis.And this is really for larger businesses and really large projects, large software projects. There's an algorithm and we basically say, okay, what are the inputs of the software, what are the outputs, what are the interfaces, what are the interfaces, what are the interfaces, what are the interfaces, what are the interfaces And they run it through an algorithm—okay, is this thing reusable? Is it portable across different platforms? How reliable, how stable is it? So you might in a larger environment see function point analysis.And then with function point analysis you'll see also feature points like okay, when we're estimating how much effort is involved, we need to see all the features, including the kinds of images, the kinds of files,how many screens will people see.And then from here, from all of this, we can kind of estimate how much this software is going to cost. You figure that an application developer makes pretty good money, and they're certainly going to make a lot more money than your system analyst, business analyst, or analyst. And so the cost of this thing is going to be directly related to the size of the thing, the lines of code, the number of people involved, and that's going to be directly related to the size of the thing, the functionality and the feature set. And then also when you consider all of this,we generally take the software and we divide it up into its major modules or features. What's the cost for each of these modules or features? And we have to worry about, OK, also, what do we do with the source code? How do we store it? How do we test it? And it's all too easy to be overly optimistic or naive about cost and scope; we're always asking ourselves, "What was the scope of this entire thing, and did we keep it reasonably within scope?" I mean, projects of scope creep happen all the time because we just didn't anticipate what resources were involved and what did we do to manage the risk from the beginning to the end.And so our final success criteria is,well, ultimately, was the client happy? That's really your ultimate success criteria,but also in the overall picture of programme management, how many projects do we have that are under common management, a common budget, and sort of a common schedule that all come together to support some business need, some business unit? Then we have a concept called portfolio management. All the projects that the organisation has going on at one time, and you can have hundreds of thousands going on at any one time in a really large organization. The importance or the context of the project, how it relates to the overallbusiness strategy, and also the project objectives. Were they smart? Were they smart? Specific measurable goals? Were they relevant? And were they time-bound or time constraint?So we need to look at all these when we're talking about project success criteria.

5. Applications

All right, let's talk about different types of applicationsand how we handle data and let's talk alittle bit about how we access the data.We have different data, applications andtechnologies when we look at thislist here called a distributed application.Now in a distributed app, you basically havemore than one computer working on something.And typically what that is, is my workstation.The client connects to a server toget some data out of it.Rather than me asking the server to do everything,I'll do some of the work and the servercan then do some of the work.So the application itself is distributed between aclient front end and a server back end.And so maybe on my client side, some checks onthe data can be run, some sanity checks to makesure that I'm not trying to put letters into azip code field or something like that.Just some basic things can be done.Maybe the data can be checked, it can be organizedsome way and then I send it over to theserver side which stores the data, retrieves something, whatever.So the concept of distributed app, the client and serverare working together and you have like two, you havethe front end and the back end of an application.Then we have this concept calledweb services and web based applications.So much of what we create andhow we access data is web based.You might not necessarily even use abrowser, but you're basically hitting a websitebecause websites are so very versatile.And like if you work in organizations, even relativelysmall ones, you're probably using an intranet website ofsome kind or you're using some kind of website.Larger organisations like us SharePoint sites or whateverso that we can do team collaboration together.And it's just web front ends.And web services so commonly in use andbeing used more and more and more.I've been on projects where teams had to veryrapidly develop something and they found that using webprotocols and web services was the quickest way todeliver this application and the quickest way to havethis application to start working.So you can have a web server.Obviously you're going to involve your infrastructure team because they'regoing to be setting up the web server, be ita virtual server or a physical box, they're going toinstall the operating system and whatever the web service is,apache or IIS or whatever it is.And they're going to put your application on thatweb server or they're going to put whatever webbased application on that web server, whatever is required.So it's not just going to be thedevelopers, but you're also going to have theinfrastructure team as well working with you.So web services and web basedapplications, extremely popular, extremely common.There are whole disciplines to managing the security of websitesand web based applications and making sure that processes thatreceive this input from a browser or even some littlefront end that doesn't look like a browser but stilluses Http or Https, that these processes run in theirown separate memory pools and then they can be killedand then they can be managed and recycled.And so there's a whole you'll need your infrastructure teamto be working with you to make sure that ifyou do Webbased applications, that it runs properly and realizethat the website itself is just usually a front end.It doesn't have the data at all.The data is in a back end in somekind of database, like a SQL version database.And then there are tonnes of different versions of SQL.You have Oracle, Transact, MySQL, you have CybaseSQL, all these different Microsoft and Oracle andthe free versions and the open source.But anyway, you're going to have a lotof moving parts working and there are securityissues with all these moving parts.Could a web based applicationbasically hack the Web server? Could I supply malicious input to the web application and there was no contingencyto to handle that malicious input? And the thing either goes crazy, there's a denialof service, it stops working or it starts executingthe code when it shouldn't be the malicious codeI've sent, or is it browsing around? I mean, back in the glory days of Windows2000, you could add a command prompt basically, or in a browser, you could basically have an IIS server do all kinds of things, including show you everything on that server, download and execute code.I mean, it was just amazing. Nobody ever thought of it. Microsoft, of course, patched it up, but that just goes to show that there are security issues with everything, and especially with Web Services and SQL Server, which is probably on a whole different box. And the communication between the web server and the SQL Server is that secure? How does the web server log on to the SQL Server to get the data? So that's why the security people need to alsobe involved with the infrastructure people in all phasesto look for potential security holes and security issues.And then we have thisconcept called N tier applications.So like if I have a web front end, I'llhave some little programme here and it could be browserbased or it uses Http in the background even thoughit doesn't seem to be browser based.And then I hit a web front end which just basicallyaccepts my input, it consumes my input and it has alittle application that runs and does something to the input.And then the web front end again is justthe thing that interfaces with me, the user.Then maybe I'll have business logic.So basically I want to order something or Iwant to get something from a database, while theweb front end will then have another tier oranother layer that runs business logic, like, okay, youcan do this, but only under these conditions orwe're going to do something to the data.So like for example, I want an application that canshow me across all markets, certain trends, and I wantto be able to slice and dice as I go.So maybe my front end, my client app,I can set my requirements and then theweb front end receives the requirements.Here the database is simply theraw warehousing of the data.So then I'll have a middle tier or an endand you can have n means any number of soI have another application between the web service and thedatabase where it's physically housed, probably on the database server.It could be a separate box, probably on the databaseserver, maybe on the web server that basically then goesand looks at specific databases and specific tables and crunchesall of that based on the criteria.So you can spread this whole thing out andyou usually offload the business logic for all thesearch onto something different and maybe the business rules.So that's the idea behind N tier.Now when we're developing systems and software, thereare a number of development mechanisms, ones thathave been around for a very long time.And once they're relatively new, theyall have their pluses and minuses.Something that so many organisations are movingto is something called agile development.We're going to talk a little bit more about that in just1 second, but it's something that we've been moving a lot toand I can tell you that in some of my situations Ihave seen where we couldn't get a major release out to saveour lives until we went to an agile development and it allowedus to get the major release out.There's also prototyping, where as the nameimplies, we just simply create a prototype.Do you like it? Okay, let's tweak it. Here's another prototype. Do you like it? Here's another one. Do you like it? And then there's rapid application development, which basically means we favour minimal planning and prototyping as opposed to the big, long, complex requirements gathering and planning of a classic SDLC.There's data oriented system development, where customers will want to be able to access data. And it's typically done to a database of some kind, like some kind of SQL database.And then there's object oriented design. And with object oriented design, rather than you just access the data directly, you access the data. It's bundled up in something called an object. And it could be a user object, clientobject, this stock inventory, some kind of object. And if you want to get into the data. And it's bundled up in something called an object. And you have to call functions called methods. These are basically functions called methods. These are basically functions called methods. These are basically functions. These are basically actions. They can act as an intermediary to get to the data. So let's take a closer look, and then we'll talk about how Agile actually works.

6. Agile Development

Okay, let's talk about agile.And it's like the name implies, you needto understand kind of where Agile came from.Before Agile we had thisvery highly formalized, structured approachcalled SDLC software development lifecycle.And with the SDLC you, you hada feasibility study and requirements gathering anddesign and development and testing and implementation,deployment and post deployment.And a very rigid version of STLC was something calledis something called Waterfall where you couldn't move to thenext stage until you had past the toll gate.People signed off, we're done.Okay, now you can move to the nextstage, hit a toll gate, you're done.Now the next and there was no going back in this way.It was very rigid.There was basically no scope creepand it would take years.Possibly one of the problems with Waterfall and SCLC isthat by the time we've totally got this done, thecustomer didn't need it anymore or the environment had changedor it just took so darn long.However, don't knock that.I mean, Waterfall got us to the moon.So I mean, it definitely has itsplace, it still has its place.But even really large Fortune 100 companiesare moving to an Agile development process.So here's what Agile is all about.It was basically developed by these developers whosaid, you know what, we're going to createsort of like our own philosophy.And they created this agile manifesto.And the manifesto basically had four statements.One is that we will favour individualsand interactions over processes and tools.We will also favour workingsoftware over complete documentation.Don't think Agile is not aboutdocumentation, but what we favour workingsoftware over documenting every single step.We favour customer collaborationover contract negotiation.One of the things that makes Agile successful isthat the customer is there with you all thetime on a daily basis, working with you tomake sure that you're always on track.And we favour responding to changeover just following a plan.Like I said before, we were working onthis one project and we just could notget the next major release out the door.We had spent a year and a half onit and it wasn't until we brought in someAgile experts and they really shook everybody up.I have to admit it completely rocked everyone's world.The developers, I mean, they were not used to thisat all, but once they adopted it, we got thatmajor release out the door and into the field.I'm not saying that it is always theend all and be all, but so manyorganizations are moving towards the Agile process.There are a variety of flavours of Agile,but let me describe what I've seen.So like in Agile you basically havevery clear time boxed periods of timecalled sprints, like typically two weeks.And in two weeks time we're onlygoing to get this much done period.And the developers they self organized.It's very sort of democratic.You don't have you do this, you do this.Instead they together figure out okay, in this amountof time we can get these things done.So there's like a stack of things we'dlike to get done that the customer wantsspecific little features and they don't even haveto be like a complete working product.It's like one thing we want to get done and youhave a stack of these and the developers sit together andthey go okay, this will take this much effort, this willtake this much effort, this will take this much effort.OK, within two weeks time we can getthis much done and everything else stays onthe stack in what's called a backlog.Backlog isn't a bad term in Agile it just meansthe stack of things we want to get done.The nice thing about it is that it reallyhelps manage customer expectation because you get the customerinvolved all the time and when the customer isthere and is seeing that and they're involved helpingyou determine OK, we've only got so much time.So the customer will choose what's important tothem so the developers can say we canget these done in the amount of time.Which ones do you want? And the customer says, okay, I want this one,that one, that one, that one and I recognizethat's it for two weeks and there's like aterm yagni, you ain't going to need it.See customers, they come in and they sayI want this and I want that.And everyone's going oh my goodness.But when you get the customer involved day to dayand they pick their priorities and that I want thisthing ended up staying on the stack and was notpart of what we're going to do.And next time around the I wantthis thing stays on the stack.After a while they say yeah, you'reright, I really don't need it.And they themselves come to the conclusion thatthese frills that they wanted really are notcrucial to the main functionality of this.It's an evolutionary process thatinvolves constant involvement of everybody.And then what you have isthe developers, they self assign.You might have like a whiteboard here that shows all thedifferent days of the week, the two weeks along the Sprintand with post its where each developer is Monday, Tuesday, andwe can see how far along we are.And if a developer is done then wego ahead and they pick up another thing.Sometimes in extreme development you'll have programmers pairprogramming where one guy's doing the main thingand the other guy is kind of checking.That's a really interesting way and it'sa really effective way as well.And then what will often happen is you'll havesomebody called a scrum master whose main job isnot to lead people but to basically keep everyoneoff their back and to make sure that nothingdistracts the developers from getting their job done.And so they have a very clear time, box time,they get it all done and then you have scrummeetings and to make sure that people aren't lounging around,the meetings go on for 2 hours.You stand, you stand in a circle so that people don't wasteany time in the meeting and they say where are we? Where are we? Where are we? So Agile is a very interesting method.Some people might not like Agile becausethey'll say, well, how do we plan? How do we know? It really is an evolutionary thing in iterative shortiterative steps and if you're trying to get somethingdone quickly, it's actually a very effective method.On the other hand, if you need to have very clear controls all the way along with clear documentation, well then waterfall.The SDLC also has its place.So we're seeing movement towards Agile more and more. Now prototyping is let me just create something really quickly that I think you might like. Do you like it? This kind of helps the customer evolve their vision of what this application, the service, or this thing should be for the customer. We might sketch it out. Or if we're developing a car, we'll carve the clay. No, I don't like it. No problem. We limp the clay back all up together and let mecarve it to look for something different or draw a sketch. So in prototypes, let me just want something up real quick. Do you like it? What don't you like? Okay, let's do another one with the changes that you want and we'll evolve it in prototypes till we get what you want. With rapid application development with Rad, basically, you're using prototypes and we're favouring prototypes and minimal planning so that we can just get stuff done quicker. We use really skilled teams and we'll use integrateddevelopment tools and we'll have all of our files and all of our code in a central location. There are plenty of tools where you can have like SVN repositories or team foundation servers where people check in and check out code and there are branches of code that people are working on. And so when you work with teams like this, one of the things you're going to want to look at is can I see your use cases and can I take a look at the code? Can I see how people have been checking things and checking them out? Not that you care about the code itself, you're nota coder, you don't know how to look at that.But you want to see the progression ofpeople doing their work and the progress andsee where things are bogging down.The project manager should also be looking at this,but the project manager should not be going in,especially in an agile environment, and interfering.Instead, the project manager talks to the scrum masterand the scrum master makes sure that everybody keepsoff of and doesn't interfere with and doesn't distractor sidetrack the developers from their two week sprint.Now with data oriented systems development, like wetalked about before, we access the data.The customer wants something to accessthe data, typically in a database.So we want to be able to view and manipulate the data.We want to be able to edit the data, adddata, run reports, track trends, look at analysis models ofthe data as opposed to object oriented, where we haveobjects which basically the data is contained in a waythat you just don't directly access it.You access it through the methodsor the functions or these procedures.So I have here an object which could be aninstance of a class and then I have the datain it and a procedure to access it.This method of this functionality, object oriented development canbe used in all kinds of development methods, includingwaterfall, STLC, including Iterative, which is basically just rapidapplication or a spiral where we do one littlething and then we add a little more andwe add a little more, we add a littlemore, or agile or prototyping.Obviously you're going to want to use computeraided tools as much as possible, especially whentesting, testing should be planned for way inthe design phase of your whole project.And so we'll want to use tools not only to test.An obvious example is I'll use a tool, I'llrun the code and it'll pop up and showme where the syntax is wrong and where somethinghas broken, where something isn't working.So I want to use automated tools to createand test software as much as I can.And here is but one example ofa computer aided software engineering tool.There are many.So when we're talking about projects, thereare plenty of risks to the successof a project at the design level.The C level people CEO.CIO CTO CEO.They're not supportive.I have definitely been in projects where theCIO, everyone says, oh, it's one of hispet projects, it's his pet project.But he's got 100 pet projects and so he's only gotso much time and energy for each of his pet projects.Maybe the scope of theproject wasn't actually wide enough.Maybe the system that wehave can't support the project.Maybe it's incapable.Maybe you're writing software that requires thatwe trash all the servers and allthe workstations and buy brand new ones.It's got to be 64 bit or it's got to be have 16gigs of Ram or a quad core CPU or a very frequent one.The organisation itself is afraid ofthe change it's going to introduce.I mean, culture is a big thingand culture is set at the top.Trying to change culture from the bottom up is sodifficult, but it is so easy if someone at thevery top says no folks, let's do this, this isa good thing, this is what we should be doing.It will change the culture so much quicker thantrying to change it from the bottom up.There's risks to implementation.Maybe the sponsorship changes.They pulled the money or theyadded money or they're not satisfied.So they're not going to give you any more moneyor it's taking too long to implement this thing.Or it's we're getting slowed down in the release.Or the timeframes are unrealistic.So often unrealistic timeframes.The client is thinking very optimistically.They're looking at the cheapest quickest wayand you have to set expectation upfront and you have to involve them.If you can't then involve them constantly, sothey can see for themselves how long somethingactually takes or how much it actually costs.And then the risk in the operations,in the rollout, we didn't train people.If you're not going to train people, why areyou rolling something out if they're not going toadopt it or know how to adopt it? There was a time when major software vendors said, you know, training should be part of any budget rollout.And so maybe we didn't train people adequately, maybe management didn't communicate to people, hey, this is what's going to happen, and didn't manage people's expectations and help them ease into using this.Maybe managers or employees sabotage simply by not cooperating, which will jeopardise what they send you when they send it.

7. Monitoring And Controlling

Let's talk about monitoring and controlling the whole project work process. As we're trying to monitor this, we've got sort of a checklist here. Let's see how they initiated the project. Let's see how they planned the project. Let's see how they executed the project. Interested in how well they did on all these things? Because as an IS auditor, we're trying to find out why did this thing happen or are they on track. If we're trying to find out the controls that are in place, then let's see how they planned and executed this project. Maybe they weren't utilising their controls or maybe there weren't controls. So this project ended up being three years instead of six months, and it was like three times as costly.Let's see how they collected performance information and measured performance information. That's one of the first things. How do you measure performance information? I had a favourite when I was in Africa because my job was to basically develop an entire training system for our country and train people, and to train staff and support staff, and to train trainers, and to basically put the whole system in place and help them develop. I brought expertise from my own background and from a developed nation to a developing nation using their knowledge of their environment with best practices, and then we figured out what worked for them because And so we came up with some specific methods for certification and certain types of exams and whatever, and I had a favourite saying, and that was that the training is not successful until I actually see it implemented in the environment.The only measure of success is the actual implementation.Everything else is just noise.And so for every project, you must identify what is your measure of success, and you must quantify it as much as possible. So then, of course, we had a measurement for success, but we also double checked to make sure that there wasn't some other reason that was giving us a false impression.So you need to identify what your measurement for success is,and then also, how are you going to collect that information and who are you going to collect it from? So I always had preferred methods of collection.I wanted to see logs and I wanted to talkto people who I was less interested in hearsay, althoughI wanted to hear what everyone had to say.But I wanted to have it from reliable sources,logged and objective sources as much as possible sothat I could quantify this data and I couldknow that we were being successful.I could measure it.And then this performance information,I had to distribute it.And I had to distribute it to the rightpeople, the people who were paying for it, thepeople who would have to work with me.And I'd have to say, this thingwe were trying isn't working so well.And we found when we actually looked at thedata, that we missed the whole thing here.And so I had to make sure that everybodywas informed so that they knew, so that theycould either give us more time, give us moreresources, or just understand why we had to takea different approach or a different tack.And so you have to think ofall these things when you're project managing.And as an Is auditor, you have to seeis the project management doing all this stuff? So each step of the project, what are the inputs into the project management plan, so how is it being executed, what's being inputted into the plan so that we can see whether or not the execution is corrrect. So how are we receiving inputs in?And the work performance information, how were we collecting the performance information? How did we know? And we were constantly on folks for not reporting. And we had to find all sorts of ways to entice them and encourage them and sometimes enforce it and sometimes have people come down on them. But we needed the data.And then when we were in the middle of something and people wanted to change this and change that, we had to have a very clear plan. Will you want to do it that way? Okay, what's the use case for it? Why? What will the benefit be? And then you didn't just do it. You didn't just allow a developer to arbitrarily change something because then he didn't realise he broke something else. I have plenty of horror stories where a developer made a last-minute change and it takes down a whole system million dollar transaction every day and takes it down for like, two, three days until they figure out what broke this whole thing. So we're going to bring in a consultant, or we're going to bring in some subject matter experts from the government or from the partner we're working with, or from another part of our company, or from some other vendor or outsourcer. And now how do we make sure that doesn't happen again? So we're going to produce outputs mostly in the form of recommendations and reports that people have to act on, obviously. And also, if we see defects, we recommend how to repair certain defects or request changes. So we're going to want to, as an IS auditor,look at what all the information came into this project, how they executed it, what tools did they use, and what were the outputs besides, you know, the application of the system you're developing, and were they used as well? So when we're performing project reviews, here are the things we need to be looking at: We want to make sure that the projectperformance is in line with the project plan.Compare it.The plan was to be like this.In reality, it was like that.We want to therefore analyse and track and monitor the risks upfront. We identified risks. When you're creating the whole design, you're trying to identify and mitigate the possible risks and have contingencies for what if we can't get the supplies on time, what if half of our staff gets delayed,what if this, what if that? And how do we deal with it? And we usually build in a buffer of time and money, but you don't have time and money forever, so you'll probably want to have the absolute must-haves, the nice to-haves, and the not-importants. And you focus on the must-haves and then add the nice to-haves if you have time and money, so that's how you have a tiered level of scope.

ExamSnap's Isaca CISA Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, Isaca CISA Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.