I think the third part of ISACA focuses on a very critical issue for managers, namely large software projects. The key issues discussed here are: why some projects are very costly, and why some projects fail to achieve the expected goals in the end. The previous sections pointed out some key factors that are very related to the processing of the software to ensure that the goals are achieved. But this section focuses on how to control any system changes that must happen unavoidably. This is very important for managers, because poor change control measures have always been the reason for the failure of such projects. Therefore, ISACA recorded recommendations for better change management control for business managers. At the same time, this provides us with a knowledge from which we can know that it is essential for a business manager to have the required change control management skills.
One of the key things I learned was to audit the change control process. According to this article, change control is the process that management uses to identify, document, and authorize changes to the IT environment. It minimizes the likelihood of interference, unauthorized changes, and errors. The method of controlling change should take the size and multi-facetedness of the earth as a priority. To ensure the project’s controllability, the project manager should fully understand the change information, measure the impact of the change implementation on the project, and then decide whether to make changes. In addition, there are six key competency areas: leadership, communications, applications, competency, authority, and standardization. Communication is the creation of a culture that recognizes the value of change management.
Once an information system is installed, the system is essentially in the maintenance phase of the systems development life cycle (SDLC). When a system is in the maintenance phase, some person within the systems development group is responsible for collecting maintenance requests from system users and other interested parties, such as system auditors, data center and network management staff, and data analysts.
Despite progress in governance, risk management, project management and certifications, media
constantly remind us that project overruns, operational disruptions and management frustration with IS/IT in their businesses still occur more frequently than one would wish.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This part assumes that everyone shares the objective that projects should be completed on time and on budget and with functionality meeting expectations and causing no disruption. However, despite progress in governance, risk management, project management and certifications, media constantly remind us that project overruns, operational disruptions and management frustration with IS/IT in their businesses still occur more frequently than one would wish. Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
From this article, I know that poor change control is a common cause of project errors. Although poor change control can lead to the failure of operational activities, the change management life cycle is very simple, so purchase or design appropriate applications The procedure is not difficult. However, it is meaningless to implement such a system without a change management strategy. If you want to change control, you can refer to related internal audit and internal control articles, or use CMBook. Establish recognition of the value of change management, the organization agrees with the common definition of change management, and regularly evaluates and improves at any time.
CMBoK covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations.Here a somewhat different audit perspective on change management, in particular on capability areas and their maturity levels, is presented.The model described here is a composite of several good practices and has six critical capability areas:
•Leadership—Sponsoring the institutionalization of change management; demonstrable senior management engagement in the application of this discipline; and defining business rules, policies and procedures, and ensuring compliance with them.
•Communications—Establishing a culture that recognizes the value of change management, that the organization shares a common definition of what change management is, and that its use is regularly evaluated and improved.
•Application—Making resources available for the practice of change management and defining those areas and/or functions where a common approach is mandatory, aiming for uniformity in practices and tools.
•Competencies—Providing training and documentation, encouraging interchanges between experienced practitioners and learners, ensuring project teams collaborate and share change management knowledge.
•Authorities—Change management policies and procedures define the approval mechanisms for proposed changes depending on the criticality, complexity and impact of the proposed change. This should also provide clear definitions of the minimum requirements for segregation of duties (SoD).
•Standardization—Aiming to have a standard approach to change management and a standard set of tools to support it, integrating the tools with project delivery processes, and ensuring that expertise and advice on change management can be readily accessed and shared.
This column focuses on what causes large software projects to have huge costs and timescales overruns and/or fail to meet expectations or, at worst, be abandoned before completion. Poor change control is a frequent cause of projects going wrong.
There are six critical capability areas, leadership, communication, application, competencies, authorities, and standardization. These capabilities areas are drawn into a sample maturity table to be audited and is ranked from levele 1-5. By auditing these six critical areas where change management have problems, problems can be more easily idenitified.
Auditors are encouraged to remind their auditees that there are always going to be ongoing problems in change management, it’s important to raise the issue with senior management and the audit committee.
This column focuses on auditing how the inevitable changes to the project are managed:
Poor change control is a frequent cause of projects going wrong.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This section focuses on how to control any system changes that must inevitably occur. This is important for managers because poor change control measures can cause such projects to fail. In addition, there are six key competency areas: Leadership, Communication, Applications, Competency, Authority and Standardization. Communication is the creation of a culture that recognizes the value of change management. Auditors are encouraged to remind their auditors that there are always ongoing issues in change management and that it is important to raise these issues with senior management and the audit committee.
After reading the article, I know that poor change control is a frequent cause of projects going wrong. The article provides a number of simple examples to show that many experienced people cannot believe that poor change control creates risk. There is a Change Management Body of Knowledge (CMBoK) that has valuable guidelines for practitioners and auditors. CMBoK also covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations. The model has six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Standardization. Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This article focuses on auditing how the inevitable changes to the project are managed poor change control is a frequent cause of projects going wrong. It assumes that people share the purpose that projects should be completed without delay and under budget, also it should meet functional expectations and cause no disruption. But despite the progress made in governance, risk management, project management, and certification, the media constantly reminds us that project overruns, operational disruptions, and managers’ frustrations with IS/IT in their businesses continue to occur more frequently than one might wish. If auditors find that change management practices are not as good as they should be, they should alert the auditee that those looking for trouble will usually find it. So What impressed me most was the Change Management Body of Knowledge (CMBOK)8, which provides valuable guidelines for practitioners and auditors. It also covers organizational change and emergency situation change; The latter is rarely seen in projects, but is common in IT operations. It presents different auditing perspectives on change management, particularly in the area of capability and its level of maturity. The model described here is a combination of several good practices with six key competency areas: leadership, communications competencies authorities standardization. Each of these headings can be split into individual lines of audit and their maturity assessed. When the model is used properly, the goal is much easier to reach levels 4 and 5.
This column assumes that everyone shares the objective that projects should be completed on time and on budget and with functionality meeting expectations and causing no disruption.
The model described here is a composite of several good practices and has six critical capability areas: leadership, communication, application, competencies, authorities and standardization. Each of these headings can be split into individual lines of audit.
This article focuses on auditing how the inevitable changes to the project are managed: Poor change control is a frequent cause of projects going wrong.
Auditing change control processes need to aware six critical capability areas: leadership, communications, application, competencies, authorities and standardization. Each of these headings can be split into individual lines of audit and their maturity assessed.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
The focus of this article is on how an auditor manages the inevitable changes to a project. If you want to change control, refer to the relevant Internal Audit and Internal Control articles, or use CMBook. CMBoK also covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations. The model has six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Establish recognition of the value of change management, the organization agrees to a common definition of change management, and conducts periodic evaluation and improvement over time. Auditors are encouraged to remind their auditors that there is always an ongoing issue in change management, and it is important to raise this issue with senior management and the audit committee.
This part focuses on how to control any system changes that must inevitably occur.
This is important for managers because poor change control measures can cause such projects to fail. In addition, there are six key competency areas: Leadership, Communication, Applications, Competency, Authority and Standardization. Communication is the creation of a culture that recognizes the value of change management.
Auditors are encouraged to remind their auditors that there are always ongoing issues in change management and that it is important to raise these issues with senior management and the audit committee.
After reading this article,I am interested in the Sample Maturity Table. It includes important attributes of change management such as Leadership, Communications, Application, Competencies, Authorities, Standardization. All these attributes are important aspects to take into account during change management. I believe that Maturity table would be a great tool for organizations. Organizations would also need to have their own matric and add their own attributes base on their core business process or nature of the business. Every organization is different than another, and the sample maturity table would be a great start point.
The article talks about whether the auditors can prevent project failure. I think although the auditors cannot determine the success or failure of the project, but they may have an impact on the success or failure of the project.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
There are six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Standardization. Each of these headings can be split into individual lines of audit and their maturity assessed and then summarized in a table.
While reading the article of the part 3 of ISACA “Auditors and Large Software Projects”, there are some things that made me feel interested, the content is in relation to whether the auditors can utilize some approaches so that stop the occurrence of the project failure in the real place. Also the article introduces some suggestions for auditor can apply to prevent the achievement of the system from stepping in the situation of failure. The following content contains these suggestions:
Firstly, to change management audit or assurance program.
Secondly, to change management guidelines from the Internal Audit Office.
Lastly, to change control audit program and internal control.
After reading the third part, I think that effective change management can provide organizations with a reliable environment for business success. Without change management, a project will be more likely to face problems and pitfalls that lead to project failure. The main purpose of change management is to control risks, that is, to minimize damage to related IT services and business operations. It will help the organization manage risks, avoid unnecessary errors and protect the IT services provided by the organization.
At the same time, I found that in terms of competence areas and maturity, such as change leadership, communication, applications, capabilities, permissions, and standardization, the audit views on change management are actually different. Sample maturity is a very good tool to help organizations evaluate current change management. Don’t ignore the importance of these attributes during the change, which will help management and control develop in the right direction.
Reading this article makes me feel that despite progress in governance, risk management, project management and certifications, media constantly remind us that businesses problems still occur more frequently than one would wish.And as an auditors finding that change management is not practiced as well as it ought to be to, we should remind our responsibility and have the courage to raise the issue with senior management and the audit committee.
Despite progress in governance, risk management, project management and certification, media
We are constantly reminded that project overruns, operational interruptions, and frustrations in restructuring IS/IT are still happening more alternatively than people hope.
When auditors find that change management is not being practiced as it should be, they should remind their auditees that those who are looking for trouble will usually find it. Therefore, it is important to have the courage to raise this issue with the senior merger and audit committee.
There are two factors that cause changes in IT projects: one is external change requirements, such as customer requirements to modify the scope of work and requirements, and the other is internal change requirements in the development process, such as modifying the source code to solve some errors found in testing. Even design. In comparison, the most difficult thing to deal with is external demand changes, because the probability of IT project demand changes is high and the workload involved is also large (especially in the later stages of the project).
Change control cannot rely solely on process control in the process. An effective method is to clearly define it beforehand. One method of ex-ante control is to clearly define it before the project starts, otherwise “change” will be impossible to talk about. Scope of work (discussed in the previous chapter); another method is review, especially the review of requirements, which is often the key to the success or failure of the project. The purpose of requirements review is not only to “confirm”, but more importantly, to find out what is incorrect and make modifications to make it as close to the “real” requirements as possible. In addition, after the requirements have passed the formal review, they should be used as an important baseline. From then on, the requirements change can be controlled.
Since the change management life cycle
is straightforward, it is not difficult to buy or
design a suitable application (there are several
commercial offerings for the reader to explore).
However, implementing such a system without a
change management policy is pointless.
The challenge is getting people to comply
with this policy for all changes to configurations,
systems, application software, access rights and
system privileges, and project plans.
I think one of the important things I’ve learned is to review the change control process. Poor change control is a common cause of project errors. The model has six key areas of competence: leadership; communications; applications; capabilities; authorities; and standardization. Auditors should remind their auditees that change management has not been put into practice as it should be, and those looking for trouble will often find it.
This column assumes that everyone shares the objective
that projects should be completed on time and on budget and
with functionality meeting expectations and causing
no disruption. However, despite progress in governance, risk
management, project management and certifications, media
constantly remind us that project overruns, operational
disruptions and management frustration with IS/IT in their
businesses still occur more frequently than one would wish.
Auditors who find that change management is not
practiced as well as it ought to be should remind their
auditees that those who go around looking for trouble usually
find it. Thus, it is important to have the courage to raise the
issue with senior management and the audit committee.
An IS auditor should perform the following when reviewing software acquisition:
• Analyze the documentation from the feasibility study to determine whether the decision to acquire a solution was appropriate (including consideration of common criteria evaluations).
• Review the RFP to ensure that it covers the items listed in this section. • Determine whether the selected vendor is supported by RFP documentation.
• Attend agenda-based presentations and conference room pilots to ensure that the system matches the vendor’s response to the RFP.
• Review the vendor contract prior to its signing to ensure that it includes the items listed.
• Ensure the contract is reviewed by legal counsel before it is signed.
• Review the RFP to ensure security responses are included by the vendor.
Six key factors for reviewing the change control process:
• Leadership-Sponsor the institutionalization of change management; senior managers have obvious involvement in the application of this discipline; define business rules, strategies and processes, and ensure compliance with these rules, strategies and processes
• Communication-establish a culture that recognizes the value of change management, the organization has a common definition of change management, and regularly evaluates and improves its use
• Application—provide resources for the practice of change management, and define those areas and/or functions that must adopt a common approach to achieve unity of practice and tools
• Competence-provide training and documentation, encourage communication between experienced practitioners and learners, ensure project team collaboration and share change management knowledge
• Authorization-Change management policies and procedures define the approval mechanism for changes based on the importance, complexity, and impact of the change. This should also provide a clear definition of the minimum requirements for separation of duties.
• Standardization-the goal is to have a set of standard change management methods and a set of standard tools to support change management, integrate these tools with the project delivery process, and ensure that the expertise and suggestions in change management can be obtained and shared at any time
I think the third part of ISACA focuses on a very critical issue for managers, namely large software projects. The key issues discussed here are: why some projects are very costly, and why some projects fail to achieve the expected goals in the end. The previous sections pointed out some key factors that are very related to the processing of the software to ensure that the goals are achieved. But this section focuses on how to control any system changes that must happen unavoidably. This is very important for managers, because poor change control measures have always been the reason for the failure of such projects. Therefore, ISACA recorded recommendations for better change management control for business managers. At the same time, this provides us with a knowledge from which we can know that it is essential for a business manager to have the required change control management skills.
One of the key things I learned was to audit the change control process. According to this article, change control is the process that management uses to identify, document, and authorize changes to the IT environment. It minimizes the likelihood of interference, unauthorized changes, and errors. The method of controlling change should take the size and multi-facetedness of the earth as a priority. To ensure the project’s controllability, the project manager should fully understand the change information, measure the impact of the change implementation on the project, and then decide whether to make changes. In addition, there are six key competency areas: leadership, communications, applications, competency, authority, and standardization. Communication is the creation of a culture that recognizes the value of change management.
Once an information system is installed, the system is essentially in the maintenance phase of the systems development life cycle (SDLC). When a system is in the maintenance phase, some person within the systems development group is responsible for collecting maintenance requests from system users and other interested parties, such as system auditors, data center and network management staff, and data analysts.
Despite progress in governance, risk management, project management and certifications, media
constantly remind us that project overruns, operational disruptions and management frustration with IS/IT in their businesses still occur more frequently than one would wish.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This part assumes that everyone shares the objective that projects should be completed on time and on budget and with functionality meeting expectations and causing no disruption. However, despite progress in governance, risk management, project management and certifications, media constantly remind us that project overruns, operational disruptions and management frustration with IS/IT in their businesses still occur more frequently than one would wish. Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
From this article, I know that poor change control is a common cause of project errors. Although poor change control can lead to the failure of operational activities, the change management life cycle is very simple, so purchase or design appropriate applications The procedure is not difficult. However, it is meaningless to implement such a system without a change management strategy. If you want to change control, you can refer to related internal audit and internal control articles, or use CMBook. Establish recognition of the value of change management, the organization agrees with the common definition of change management, and regularly evaluates and improves at any time.
CMBoK covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations.Here a somewhat different audit perspective on change management, in particular on capability areas and their maturity levels, is presented.The model described here is a composite of several good practices and has six critical capability areas:
•Leadership—Sponsoring the institutionalization of change management; demonstrable senior management engagement in the application of this discipline; and defining business rules, policies and procedures, and ensuring compliance with them.
•Communications—Establishing a culture that recognizes the value of change management, that the organization shares a common definition of what change management is, and that its use is regularly evaluated and improved.
•Application—Making resources available for the practice of change management and defining those areas and/or functions where a common approach is mandatory, aiming for uniformity in practices and tools.
•Competencies—Providing training and documentation, encouraging interchanges between experienced practitioners and learners, ensuring project teams collaborate and share change management knowledge.
•Authorities—Change management policies and procedures define the approval mechanisms for proposed changes depending on the criticality, complexity and impact of the proposed change. This should also provide clear definitions of the minimum requirements for segregation of duties (SoD).
•Standardization—Aiming to have a standard approach to change management and a standard set of tools to support it, integrating the tools with project delivery processes, and ensuring that expertise and advice on change management can be readily accessed and shared.
This column focuses on what causes large software projects to have huge costs and timescales overruns and/or fail to meet expectations or, at worst, be abandoned before completion. Poor change control is a frequent cause of projects going wrong.
There are six critical capability areas, leadership, communication, application, competencies, authorities, and standardization. These capabilities areas are drawn into a sample maturity table to be audited and is ranked from levele 1-5. By auditing these six critical areas where change management have problems, problems can be more easily idenitified.
Auditors are encouraged to remind their auditees that there are always going to be ongoing problems in change management, it’s important to raise the issue with senior management and the audit committee.
This column focuses on auditing how the inevitable changes to the project are managed:
Poor change control is a frequent cause of projects going wrong.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This section focuses on how to control any system changes that must inevitably occur. This is important for managers because poor change control measures can cause such projects to fail. In addition, there are six key competency areas: Leadership, Communication, Applications, Competency, Authority and Standardization. Communication is the creation of a culture that recognizes the value of change management. Auditors are encouraged to remind their auditors that there are always ongoing issues in change management and that it is important to raise these issues with senior management and the audit committee.
After reading the article, I know that poor change control is a frequent cause of projects going wrong. The article provides a number of simple examples to show that many experienced people cannot believe that poor change control creates risk. There is a Change Management Body of Knowledge (CMBoK) that has valuable guidelines for practitioners and auditors. CMBoK also covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations. The model has six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Standardization. Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
This article focuses on auditing how the inevitable changes to the project are managed poor change control is a frequent cause of projects going wrong. It assumes that people share the purpose that projects should be completed without delay and under budget, also it should meet functional expectations and cause no disruption. But despite the progress made in governance, risk management, project management, and certification, the media constantly reminds us that project overruns, operational disruptions, and managers’ frustrations with IS/IT in their businesses continue to occur more frequently than one might wish. If auditors find that change management practices are not as good as they should be, they should alert the auditee that those looking for trouble will usually find it. So What impressed me most was the Change Management Body of Knowledge (CMBOK)8, which provides valuable guidelines for practitioners and auditors. It also covers organizational change and emergency situation change; The latter is rarely seen in projects, but is common in IT operations. It presents different auditing perspectives on change management, particularly in the area of capability and its level of maturity. The model described here is a combination of several good practices with six key competency areas: leadership, communications competencies authorities standardization. Each of these headings can be split into individual lines of audit and their maturity assessed. When the model is used properly, the goal is much easier to reach levels 4 and 5.
This column assumes that everyone shares the objective that projects should be completed on time and on budget and with functionality meeting expectations and causing no disruption.
The model described here is a composite of several good practices and has six critical capability areas: leadership, communication, application, competencies, authorities and standardization. Each of these headings can be split into individual lines of audit.
This article focuses on auditing how the inevitable changes to the project are managed: Poor change control is a frequent cause of projects going wrong.
Auditing change control processes need to aware six critical capability areas: leadership, communications, application, competencies, authorities and standardization. Each of these headings can be split into individual lines of audit and their maturity assessed.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
The focus of this article is on how an auditor manages the inevitable changes to a project. If you want to change control, refer to the relevant Internal Audit and Internal Control articles, or use CMBook. CMBoK also covers organizational change and emergency changes; the latter appears rarely in projects, but is common in IT operations. The model has six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Establish recognition of the value of change management, the organization agrees to a common definition of change management, and conducts periodic evaluation and improvement over time. Auditors are encouraged to remind their auditors that there is always an ongoing issue in change management, and it is important to raise this issue with senior management and the audit committee.
This part focuses on how to control any system changes that must inevitably occur.
This is important for managers because poor change control measures can cause such projects to fail. In addition, there are six key competency areas: Leadership, Communication, Applications, Competency, Authority and Standardization. Communication is the creation of a culture that recognizes the value of change management.
Auditors are encouraged to remind their auditors that there are always ongoing issues in change management and that it is important to raise these issues with senior management and the audit committee.
After reading this article,I am interested in the Sample Maturity Table. It includes important attributes of change management such as Leadership, Communications, Application, Competencies, Authorities, Standardization. All these attributes are important aspects to take into account during change management. I believe that Maturity table would be a great tool for organizations. Organizations would also need to have their own matric and add their own attributes base on their core business process or nature of the business. Every organization is different than another, and the sample maturity table would be a great start point.
The article talks about whether the auditors can prevent project failure. I think although the auditors cannot determine the success or failure of the project, but they may have an impact on the success or failure of the project.
Auditors who find that change management is not practiced as well as it ought to be should remind their auditees that those who go around looking for trouble usually find it. Thus, it is important to have the courage to raise the issue with senior management and the audit committee.
There are six critical capability areas: Leadership; Communications; Application; Competencies; Authorities; Standardization. Each of these headings can be split into individual lines of audit and their maturity assessed and then summarized in a table.
While reading the article of the part 3 of ISACA “Auditors and Large Software Projects”, there are some things that made me feel interested, the content is in relation to whether the auditors can utilize some approaches so that stop the occurrence of the project failure in the real place. Also the article introduces some suggestions for auditor can apply to prevent the achievement of the system from stepping in the situation of failure. The following content contains these suggestions:
Firstly, to change management audit or assurance program.
Secondly, to change management guidelines from the Internal Audit Office.
Lastly, to change control audit program and internal control.
After reading the third part, I think that effective change management can provide organizations with a reliable environment for business success. Without change management, a project will be more likely to face problems and pitfalls that lead to project failure. The main purpose of change management is to control risks, that is, to minimize damage to related IT services and business operations. It will help the organization manage risks, avoid unnecessary errors and protect the IT services provided by the organization.
At the same time, I found that in terms of competence areas and maturity, such as change leadership, communication, applications, capabilities, permissions, and standardization, the audit views on change management are actually different. Sample maturity is a very good tool to help organizations evaluate current change management. Don’t ignore the importance of these attributes during the change, which will help management and control develop in the right direction.
Reading this article makes me feel that despite progress in governance, risk management, project management and certifications, media constantly remind us that businesses problems still occur more frequently than one would wish.And as an auditors finding that change management is not practiced as well as it ought to be to, we should remind our responsibility and have the courage to raise the issue with senior management and the audit committee.
Despite progress in governance, risk management, project management and certification, media
We are constantly reminded that project overruns, operational interruptions, and frustrations in restructuring IS/IT are still happening more alternatively than people hope.
When auditors find that change management is not being practiced as it should be, they should remind their auditees that those who are looking for trouble will usually find it. Therefore, it is important to have the courage to raise this issue with the senior merger and audit committee.
There are two factors that cause changes in IT projects: one is external change requirements, such as customer requirements to modify the scope of work and requirements, and the other is internal change requirements in the development process, such as modifying the source code to solve some errors found in testing. Even design. In comparison, the most difficult thing to deal with is external demand changes, because the probability of IT project demand changes is high and the workload involved is also large (especially in the later stages of the project).
Change control cannot rely solely on process control in the process. An effective method is to clearly define it beforehand. One method of ex-ante control is to clearly define it before the project starts, otherwise “change” will be impossible to talk about. Scope of work (discussed in the previous chapter); another method is review, especially the review of requirements, which is often the key to the success or failure of the project. The purpose of requirements review is not only to “confirm”, but more importantly, to find out what is incorrect and make modifications to make it as close to the “real” requirements as possible. In addition, after the requirements have passed the formal review, they should be used as an important baseline. From then on, the requirements change can be controlled.
Since the change management life cycle
is straightforward, it is not difficult to buy or
design a suitable application (there are several
commercial offerings for the reader to explore).
However, implementing such a system without a
change management policy is pointless.
The challenge is getting people to comply
with this policy for all changes to configurations,
systems, application software, access rights and
system privileges, and project plans.
I think one of the important things I’ve learned is to review the change control process. Poor change control is a common cause of project errors. The model has six key areas of competence: leadership; communications; applications; capabilities; authorities; and standardization. Auditors should remind their auditees that change management has not been put into practice as it should be, and those looking for trouble will often find it.
This column assumes that everyone shares the objective
that projects should be completed on time and on budget and
with functionality meeting expectations and causing
no disruption. However, despite progress in governance, risk
management, project management and certifications, media
constantly remind us that project overruns, operational
disruptions and management frustration with IS/IT in their
businesses still occur more frequently than one would wish.
Auditors who find that change management is not
practiced as well as it ought to be should remind their
auditees that those who go around looking for trouble usually
find it. Thus, it is important to have the courage to raise the
issue with senior management and the audit committee.
An IS auditor should perform the following when reviewing software acquisition:
• Analyze the documentation from the feasibility study to determine whether the decision to acquire a solution was appropriate (including consideration of common criteria evaluations).
• Review the RFP to ensure that it covers the items listed in this section. • Determine whether the selected vendor is supported by RFP documentation.
• Attend agenda-based presentations and conference room pilots to ensure that the system matches the vendor’s response to the RFP.
• Review the vendor contract prior to its signing to ensure that it includes the items listed.
• Ensure the contract is reviewed by legal counsel before it is signed.
• Review the RFP to ensure security responses are included by the vendor.
Six key factors for reviewing the change control process:
• Leadership-Sponsor the institutionalization of change management; senior managers have obvious involvement in the application of this discipline; define business rules, strategies and processes, and ensure compliance with these rules, strategies and processes
• Communication-establish a culture that recognizes the value of change management, the organization has a common definition of change management, and regularly evaluates and improves its use
• Application—provide resources for the practice of change management, and define those areas and/or functions that must adopt a common approach to achieve unity of practice and tools
• Competence-provide training and documentation, encourage communication between experienced practitioners and learners, ensure project team collaboration and share change management knowledge
• Authorization-Change management policies and procedures define the approval mechanism for changes based on the importance, complexity, and impact of the change. This should also provide a clear definition of the minimum requirements for separation of duties.
• Standardization-the goal is to have a set of standard change management methods and a set of standard tools to support change management, integrate these tools with the project delivery process, and ensure that the expertise and suggestions in change management can be obtained and shared at any time