Did you know Cybrary's video training is FREE? Join more than 2,500,000 IT and cyber security professionals, students, career changers, and more, growing their careers on Cybrary.
This lesson discusses decoding the strategy for IT. Basically, for each department that generates revenue for a company, we must know their responsibilities. This lesson also discusses strategies: - Advisory - Regulatory - Informational This unit also discusses project and program management along with project and quality control management models, IT strategies and sourcing methods. [toggle_content title="Transcript"] Alright, so let's talk now about how we decode the strategy for IT. There are lots of things to think about here. One of the top priorities is having a step-by-step workflow. This means that for each area of the organization that generates some kind of revenue, we should know, step-by-step how that happens. Who's involved, what are their tasks, what are their responsibilities? As it relates to that workflow we need to think about where the risks are in each of those steps. It could be that certain areas of the workflow are problematic because you're dealing with some sensitive information, or maybe there's some time delays and different things, so there's some risk associated with that that needs to be understood. Any kinds of triggers for events need to be understood and documented. So if a unforeseen event happens, how does that effect the IT strategy? Or maybe you've got another perspective where you're thinking, 'Well, we've got a regular review or regular audit, a regular self-assessment, and now I have to understood that kind of an event; a scheduled event, and how it relates to the strategy for IT. If events do happen and we have to deal with them, we should think about contingencies. What do you do if your primary source of information or your primary mechanism for achieving your workflow goes away? Especially if you've got third parties involved. That's an extra level of risk to consider. Then, ultimately, if you can do this step-by-step analysis, it might be possible to find areas where improvements can be made, or some optimization or a more efficient way of doing things could be uncovered just by doing the analysis of the workflows themselves. There's different ways to fund your IT strategy. The typical way that a lot of organizations do this is sharing the cost. So this is a great way to make things a little bit simple and that way everyone that's part of the organization gets some benefit from the expenditure on resources for IT. They all just, sort of, get their piece of the pie, so to speak. Other organizations might use a charge back mechanism. I've seen this in several places that I've worked where you've got maybe a systems engineering or network engineering group that fields requests from other areas of their organization. 'We need a new firewall set-up. We need a new system built to house our applications.' So one organization does the work, they come up with the mechanism to place a value on that; some billing unit, whatever it is. And they charge the other business unit for that time. So the money's moving around within the organization from one budget to another. The last option that you might see is where the sponsor pays the bills. This is another effective way to do this, because now you're being more specific as far as who's paying for the effort, having a tighter linkage to who benefits from the effort. With the possible disadvantage that people that are part of that organization or that division might benefit from some of this expenditure without actually having to contribute any resources to make it happen. So really just understanding the three basic mechanisms here is the most important thing. Most likely, as an auditor, you're not going to be in a position to influence the choices of the management in one way or another, as far as the way they like to do things. We have to consider different types of policies. Much like the policies and guidelines and standards that we talked about in the previous module, we have to think about the different levels of enforcement here. So something that's an advisory policy is just giving advice. It's not considered a hard requirement, but is more about suggesting best practices or the best way to do things in a given situation. A regulatory policy, on the other hand, means that now we're dealing with laws. And, of course, this is something that is mandatory and cannot easily be avoided and the consequences should be well understood for not following a regulatory policy. Then the last we have is informational policies. So these are things that help users of services and products, or other people within the same organization, actually, to do their job better. This is more information more detail, and that should be considered a helpful thing, but, again, not mandatory, not necessarily enforced. We have to think about program management. So I mentioned the project management office earlier. This kind of relates to that in the sense that we're trying to make sure that all of the different projects that are in progress, that are supporting the business objectives, are being managed correctly. This management would include things like budgeting, timeline, personnel resources, and so on. So the project management or the program management effort needs to keep tabs on all these details to make sure the organization is doing what it's supposed to do, in the timeframe and budget that's been allocated. So, as long as an organization is in business, there'll be some need for management of its projects and programs. There might be cases where certain things are actually ceased or terminated and now the program management office would have to adjust its priorities accordingly. So what are the kinds of things or programs that are going to be sustained for long-term? We have marketing, HR, payroll, all of your accounting and book-keeping, the maintenance of your facility - Making sure that you've got compliance with all the laws and regulations. These are things that are always going to be required as long as the organization is in business. Then we have project management. This is a way to deal with the programs that the organization is involved in - Trying to measure the risk, trying to manage it, trying to understand whether or not the resources that have been allocated are adequate and are being properly utilized. We have different considerations. If you've got a capital project, that's dealing with the entire enterprise, versus something that's much smaller, that might just be for a particular team or a business division within the organization. So some examples might be new product development, updates to systems and software, audits of individual systems, or even individuals themselves. So the PMO, the project management office, tries to keep track of all the projects, maintain visibility to the people that need to know about them, basically the stakeholders, and, as a project manager, keeping tabs on all the individuals doing their various tasks and trying to make sure that people meet their deadlines and their deliverables. You might have a PMO that works in a generic sense for the organization and says that any new project that gets initiated must get reviewed by the PMO to decide who will work on it, which subject matter experts are appropriate, and there should be some agreement on different aspects of how long the project should take and what kind of funding might be required. We have a master project register for mature organizations. That's sort of like another consideration for managing your portfolio. If I've got fifteen projects in progress, I want to be able to look at the master project register and see all the details that are needed to understand who's responsible for this project, when did it start, how much money is allocated, when will it be expected to be completed, and so on? So some different models we can consider; we have the PMI, the Project Management Institute. So people that achieve a PMI certification would get that from this organization. So these are projects that are unique or things that repeat. Using the maturity model of level 0-3, we know that the capability maturity model goes from 0-5, but they're just dealing with levels 0-3 typically. So 42 process areas, looking at what the project manager does, how their methodologies and techniques are used in order to further the goals of each individual project. Then we have PRINCE2, otherwise known as P2. This is a standard for the UK. Again, for unique or repeating projects, and targets the same capability maturity levels that the PMI does. They have a slightly different make up with nine process areas instead of 42, but with a focus on the methodology to try to achieve the goals of each project owner. Then we have Total Quality Management, or TQM. Referring more to the quality management of each individual project. That's why it targets level 3-5 of the capability maturity model. So this wouldn't be used until a project is in a more mature stage and you're trying to get to the point when you're refining and optimizing. Then we've got Six Sigma: something that was created by Motorola to try to reduce defects. For instance, 16000 defects per million was reduced to 3.4 defects per million. That's Six Sigma, otherwise known as 'the five nines'. So it's 99.999% perfect. It's a very high standard to achieve, and Motorola did this when they were developing their mobile phones, back in the days when they were the world leader in mobile phone production. Lastly we have the ISO 9001 series. Again, related to quality control, just like Six Sigma and Total Quality Management. This is to say that if we want to have repeatable quality control efforts, that deal with CMM 3-5, just like Six Sigma and Total Quality Control does, and it tries to incorporate all of the ISO 9000 quality standards in an international context. Alright, so now let's talk about planning our IT strategy. How do we implement the strategy from a planning perspective? The organization needs to consider operational long-term and strategic goals, or you could say short-term, mid-term and long-term goals if you want to use a different language for that. So if that's the context that you're in, then when you're creating a new IT project it should be clearly identified whether this is a short-term, mid-term or long-term project. That would affect the level of resources required to achieve the completion of the project. A long-term project or a strategic project would understandably take more time and money, and potentially more people as well. So having a plan for how the data will be managed and handled, the data that's being transmitted, processed and stored, where does that happen? How does it happen? That should be well understood and documented accordingly. There should be a plan for managing all of the applications that the environment uses. This not only includes money for purchasing new software, but how do you deal with managing all of the licenses that are currently in existence? How is that resource going to be allocated on a short-term, mid-term and long-term basis? We have to have a plan for technology. A lot of organizations do what's called a tech refresh. So every two to three years, maybe everybody gets new laptops or you upgrade all of your servers. You upgrade your firewalls or your proxies. These are things that organizations do in order to make sure that they're always using something that's state-of-the-art, or near state-of-the-art as long as it's within the resources that they've got available for spending on such items. Then you have to think about the organizational plan, so how does IT support the goals of the business? How does it align itself with the business strategy to product products and services that can further the goals of the organization to attract new customers, to continue to grow the business and increase revenues? Then you might also consider a facilities plan. In this day and age, where more and more organizations are using managed services, or cloud computing, a facilities plan needs to take those kinds of things into account. Are you going to continue to host all of your servers within your own data center, or are you going to outsource some of this? There are trade-offs, of course, to both scenarios. What about COBIT? This is an ISACA developed standard. It's the control objectives for information related technology. So this gives a comprehensive way to deal with the strategy, formulation, monitoring your processes, and developing procedures to help an IT organization move forward. Currently, COBIT is in its fourth revision or edition. Of course we'll talk a little bit more about this in some later sections as well. So sourcing locations, what do we mean by a sourcing location? This means we're thinking about whether a resource can be achieved from within the organization, so that's called insourcing, or in-house, or do we want to get some product, service, or other resource from outside the organization we're in? We call that outsourcing. There are different advantages to both. Typically we're looking at operating cost and labor costs when making these kinds of decisions. If you move your production of, or creation of products, of factories, and any kind of labor like that, a lot of organizations will move those things to countries where the labor is cheaper, like China, for instance. A lot of products are made in China because the costs of production are much lower there. But, of course, there are some disadvantages. If you move too many things off-shore or outsource them, then you may lose control of some of your little intellectual property. There may be quality control issues that don't get addressed in a timely fashion and now you're taking shipments of products that have defects and they have to be reworked or sent back to the manufacturer. So these are stories that probably everyone has seen in the news regarding the example I used in an earlier chapter where children's toys were produced that contain lead paint. So they had to be pulled from the market and the manufacturer lost a lot of money on that because they outsourced it to a Chinese company, perhaps, and the Chinese company took shortcuts, and now there are problems because of that. So something to think about, the pros and cons here. Saving money but possibly other headaches later. What about services that get fulfilled from remote locations? One of the most common ways that we come into contact with this is when you call tech support for a given company and you get someone on the phone who doesn't appear to be an English speaker as a first language. Maybe they speak Okay English but it's not their first language so there might be some communication challenges - Again, cheaper labor but potentially dissatisfied customers if they can't communicate very well with the person on the other end of the line. Other services can also be outsourced. We can outsource accounting and book-keeping, data entry, telephone support. Doing your printing or software development might be ideal things. Printing might be something that's a lower risk choice since there might be less things that can go wrong in that kind of a context, perhaps. So be aware of the types of services that can be used and some of the pros and cons of insourcing versus outsourcing. So we can also, in addition to insourcing or outsourcing, have what's called a hybrid; where you do some things in-house, some things done outside of the organization. Is there an advantage to sending something off-shore for additional processing or additional manufacturing steps? That might be a consideration. Or maybe a very complex product is built, the components are built within the organization and they're assembled somewhere else, because the labor for assembly is cheaper but we're not worrying about the design aspect because we're going to take care of that in-house. So there's trade-offs, again, for different ways that might be done. You have to think about legal issues. If you're using workers from another country, they might have different expectations, different legal rights compared to the home country where the organization is located. So that's something to consider, as far as a way of doing business. For instance, the European Union has very different privacy laws than what we have in the US. In many ways, their privacy laws are actually superior to ours. You've got more protection for your privacy in some ways in the EU than you do in America. China with basically non-existent intellectual property laws. Their idea of producing a product that is effectively an exact copy of someone else's is much different than what we think of here in the US. We think someone that does that is stealing. From their perspective they're not stealing, they're just trying to compete with you the best way they know how. So we have to be aware of those differences, culturally and legally, between different countries that are doing business together. What about using sub-contractors? This entails some liability. The sub-contractor makes a mistake, or they are doing something illegal, it may be the case that the organization that hired the sub-contractor ends up with a penalty or the blame. The sub-contractor may not be legally liable or even in a position to be prosecuted or approached for reparations or damages. So there could be some grey areas that need to be well understood before engaging in certain types of activities with sub-contractors or third parties. So be aware of some of those pitfalls and how they might apply to an organization. You will see questions on the exam asking about some of these kinds of situations. You might be able to get certain types of insurance to help with protecting the organization in the event of certain problems occurring. The insurance might have limitations in far as where it's enforceable and where it might be unenforceable. [/toggle_content]