The interesting possibilities that it companies have invested lots of resources that help them streamline their key procedures, they include the development, acquiring, integration and the maintenance of the software system. These are the parts required for the life cycle process of any business application development. The process of implementing applications in business follows the project planning and processes of management as outlined. The development of application of business project has to start with an individual .When an individual applies the state of assessment of a proposed plan it is introduced as a result of more than one of the following circumstances: A fresh chance that relates to a fresh existing process of business, A problem that narrates to a current business process, the current technology problem, A fresh opportunity that will improve the company to take benefit of technology.
These circumstances are firmly combined with key business drivers. Key business drivers, in this setting, can be characterized as the qualities of a business work that drive the conduct and usage of that business capacity to accomplish the key business objectives of the organization.
Advantages of utilizing this methodology are that every single influenced gathering will have a typical and unblemished comprehension of the destinations and how they add to business support. Furthermore, clashing key business drivers and commonly subordinate key business drivers can be distinguished and settled in beginning periods of a SDLC venture.
Business application ventures ought to be started utilizing very much characterized systems or exercises as some portion of a characterized procedure to convey business needs to the executives. These techniques frequently require natty gritty documentation distinguishing the need or issue, indicating the ideal arrangement also, relating the potential advantages to the association. All inward and outer components influenced by the issue and their impact on the partnership ought to be distinguished.
A hazard in any product improvement venture is that the ultimate result may not meet all prerequisites. Issues because of interpretation blunders emerge when at first characterizing the necessities for interval items. The cascade model and variations of the model ordinarily include an actual existence cycle confirmation approach that guarantees that potential errors are redressed early and not exclusively amid conclusive acknowledgment testing.
165-183
One point is the user involvement in the design. After business process have been documented and it is understood how those processes might be executed in the new system, involvement of users during the design phase is limited. Given the technical discussion that usually occurs during a design review, end-user participation in the review of detailed design work products is normally not appropriate. However, developers should be able to explain how the software architecture will satisfy system requirements and outline the rationale for key design decisions. Choices of particular hardware and software configurations may have cost implications of which stakeholders need to be aware and control implications that are of interest to the auditors.
One thing of interest I took away from “CISA Chapter 3.5 “Business Application Development” would be the topic of “integrated resource management systems.” Within this topic, it mentioned that an integrated solutions implementation is a very large software acquisition project. For example, the acquisition and implementation of an ERP system impacts the approach the company does their business, which including the company’s entire control environment and technological direction. In terms of the scale of this, I think a thorough impact and risk assessment should be conducted.
Enterprise resource planning is a business process management software that allows an organization to use a system of integrated applications to manage the business and automate many back-office functions related to technology, services, and human resources.
Instead of several standalone databases with an endless inventory of disconnected spreadsheets. ERP systems bring order to the chaos so that all users—from the CEO to accounts payable clerks—create, store, and use the same data derived through common processes. With a secure and centralized data repository, everyone in the organization can be confident that data is correct, up to date, and complete. Data integrity is assured for every task performed throughout the organization, from a quarterly financial statement to a single outstanding receivables report, without deploying error-prone spreadsheets.
Implementation is the process that turns strategies and plans into actions in order to accomplish strategic objectives and goals. The implementation process for business applications follows the project planning and management process as outlined previously. The business application development project begins when an individual application feasibility study is initiated as a result of one or more situations. All of these situations are tightly coupled with key business drives. Which in this context, can be defined as the attributes of a business function that drive the behavior and implementation of that business function to achieve the strategic business goals of the company. Therefore, all critical business objects have to be translated into key business SDLC project. So that general requirement will be expressed in scorecard form, which allows objective evidence to be collected in order to measure the business value of an application and to prioritize requirements.
After thoroughly reading through Section 5 of Domain 3 in the CISA textbook, which primarily focused on the topic of “Business Application Development”, I started to take note of the application development models described that we also talked about in class on various occasions. Among those application development models were the waterfall model and the verification-validation model, which the text notes as being able to help companies mitigate their risks of not meeting business requirements set during earlier phases of development. The textbook goes on to further explain that implementing these models mitigates risk by providing points in the software development life cycle where testing and analysis occur so as to catch and correct errors in the early stages of development. The textbook also mentioned one of the more thorough and time consuming forms of testing for software which I was not very familiar with, that being unit testing. After reading about unit testing briefly in the textbook, I dug around the internet a little bit for a little more information regarding it and found that it is considered the most thorough because it is the most micro-oriented form of testing where you analyze very small sections of the code right after completion.
Hi Jordan,
Great observations and take-away from this chapter. It is indeed there are many models of testing your application. Testing is the step before applying to the real system so this is very important. And you mentioned that there are many forms of software, which is what I found also interesting from this Chapter’s reading. Many softwares are focusing on one main utility but vary at the micro level.
My key take-away from CISA Chapter 3.5 “Business Application Development” is Phase 6 of SDLC which is “Post Implementation Review”. Post-Implementation Review (PIR) is conducted after completing a project. Its purpose is to evaluate whether project objectives were met, to determine how effectively the project was run, to learn lessons for the future, and to ensure that the organization gets the greatest possible benefit from the project. PIR helps in validating that all components of the SDLC are present in the completed project documentation:
– The project plan is updated and finalized
– Requirements were documented, approved and finalized
– Program design were documented
– Test plans, procedures and results were documented
– Issues lists were maintained
– An implementation plan was finalized
Under this section of CISA manual, it emphasizes that IS auditor performing this review should be independent of the system development process and therefore, IS auditors who were involved in consulting of project development should not perform this review.
Hello,
Reading through what you found as the most interesting part of the CISA textbook module 3 segment 5 on “Business Application Development” truly helped paint a more vivid picture of points that the CISA textbook was trying to get across. I appreciate you putting in the effort to list what is often validated in regards to finalized documentation during the post-implementation review, as it shows that you have developed an appropriate understanding and can even help explain concepts to others. I also appreciate the small note included at the end which emphasized how important it is that the IS auditors performing the reviews are different from those who were consulted during the development process, for independence’s sake.
The interesting thing that I took away from CISA chapter 3.5 is phased changeover. Phased changeover brake the old system into deliverable modules and then phased each old module by replacing the newer relevant system. This is a cheaper way compare with the parallel, and it’s also a less risky way compare with Abrupt changeover. However, there are some risks that may exist such as resources challenges from both the IT side and the operation side, an extension of the project life cycle to cover two systems, and change management for the ongoing replacement of the old system by deliverable modules. I would consider that change management would be the riskiest.
Good points, Shuyue! I found the changeover techniques interesting too. Deciding which changeover technique will work best for a particular organization depends on the type of changeover and level of risk for that organization. Touching on disadvantages for each technique— abrupt, or direct, changeover carries the most risk because if something goes wrong, reverting back to the old system is usually next to impossible. The disadvantage for phased changeover is that the process takes a while to complete because the phases need to be implemented one by one. Lastly, a disadvantage for parallel changeover is that since the two systems are running simultaneously, there are higher costs associated with this particular technique.
Hi Shuyue, I agree as well. The phased changeover is the most logical changeover technique to me as well because it has the least risk and cost compared to the abrupt and parallel changeover. Running both systems during parallel changeover will incur an unnecessary cost for the company. There are many risks with the abrupt changeover, and there are too many security areas that can go wrong with directly cutting off and switching to a new system.
I find that the phase 6 of business application development, postimplementation review is also important within the whole process. As the book mentions, project implement team and appropriate end users, or an independent group not associated with project implementation can perform a postimplementation review after all the design finished. The postimplementation review should include various aspects including assess the adequacy of the system, evaluate the projected cost benefits or ROI measurements, develop recommendations and plan for implementation and assess the development project process. These reviews are the bottom line against any design vulnerabilities through the participation of others who with different perspectives, to find problems that implementation team fail to pay attention to. The postimplementation reviews should make sure all the goals are met, or provide valuable guidance if there are any problems. The object of the review is the current status and output, and the purpose of the review is to ensure the final correct output will be delivered.
Hi Yuqing, You did a great job by emphasing on independence of users performing post implementation review. This is a key point to consider as an IS auditor. Segregation of duties need to be verified during the post implementation review testing and we need to ascertain that no users from development, testing or implementation team be part of post implementation review.
There is often a difference of opinion as to who should perform the Post-Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to work, how to fix problems, etc.
There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review.
A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. The project team might then reconvene to consider that input and also to examine how to generate further value from the solution.
Hi Yuqing, I think you are right. I also believe that the post-implementation review a critical part. Post-implementation review is the last step in your project cycle and usually involves an independent party, which can act more objectively in making their determinations about how the project was run. I think it will make the whole process complete.
Hi yuqing, I like your opinion. You pointed out how can the project benefits from post-implementation and the critical steps to complete post-implementation review. To Sum up,The post implementation review is the last critical step in the project life cycle and it is very important. It needs to ensure all project make their goals and identify project achievements and what went right or weaknesses and what went wrong.
Certification is a process by which an assessor organization performs a comprehensive assessment against a standard of management and operational and technical controls in an information system. The assessor examines the level of compliance in meeting certain requirements such as standards, policies, procedures, work instructions and guidelines requirements made in support of accreditation. The goal is to determine the extent to which controls are implemented correctly, operating as intended and pricing the desired outcome with respect to meeting the system’s security requirements. The results of a certification are sued to reassess the risk and update the system security plan, thus providing the factual basis for an authorizing official to render an accreditation decision.
Great comments! Thank you for sharing the definition of certification with us. I agree with you that the goal of this is to implement the controls effectively.
CISA Manual Chapter 3.5 “Business Application Development” p. 181-182 had several sections with one section drawling most of my attention — Phase 6 — Postimplementation Review (PIR). The post implementation review very important and is conducted to ensure that the system meets design and development specifications as well as control requirements. One interesting aspect of the PIR is that the information to be analyzed is collected during prior analysis phases. For instance, during the feasibility and design phases, a lot of the requirements and specifications to be analysed will first be mentioned here. In terms of who will be involved, members for the development team, end users, and business analysts should be included in the review. Aside from the IT Auditor — a third part group outside of the project should evaluate the functionality of the system to remove any confirmation bias.
Great point. Postimplementation Review is very important.
For example, after completing a year-long project to establish a new quality management process for your organization, you want to make sure that what you set out to do was actually achieved. Your objective wasn’t to simply deliver a process – but rather, to deliver the process that addresses the specific business need you intended to meet. This is the real measure of success.
Nice points- I found these interesting as well. Involving an outside party allows for us to know if the system is truly user friendly since they would be conducting an objective review, rather than solely basing functionality off the opinion of developers or others who have been involved throughout the SDLC and are familiar with the system.
I found the section integrated resource management systems interesting. Lots of organizations are shifting from separate groups of interrelated applications to a fully integrated corporation solution. Such solutions are often marketed as ERP solutions. ERP solutions commercial application such as SAP, Oracle Financials or SSG are all pretty useful tools for corporations.
The business opts to change business processes to suit the industry standard as dictated by the software solution. The whole idea of ERP system shows the strength of integrated as a whole should be better than separated standalone applications.
Advantages of ERP:
1. Complete visibility into all the important processes, across various departments of an organization (especially for senior management personnel).
2. Automatic and coherent workflow from one department/function to another, to ensure a smooth transition and quicker completion of processes. This also ensures that all the inter-departmental activities are properly tracked and none of them is ‘missed out’.
3. A unified and single reporting system to analyze the statistics/status etc. in real-time, across all functions/departments.
4. Since same (ERP) software is now used across all departments, individual departments having to buy and maintain their own software systems is no longer necessary.
Postimplementation reviews are interesting in that there are two approaches: one being an internal review from the project development team and end users, and the second being a review from an independent source that was unassociated with the project itself, such as auditors. We can appreciate both of these system review approaches, as the developers and end users are typically concerned with usability, while independent auditors are mostly concerned with the system control features during the development and implementation phases. Effectively, it’s important to note that in order for these reviews to be successful, the information that is reviewed should be identified during the feasibility study and design phase, with progress being documented as the project moves forward. It’s interesting that the end of the project still relies on the early stages of project development, not only in a technical aspect, fact being that documentation is vital from the beginning in order for those involved to successfully complete each task.
The interesting I took away from chapter 3.5 is the feasibility study in traditional SDLC phases. As mentioned in the book, the traditional SDLC approach is made up of a number of distinct phases each with a defined set of activities and outcomes. A feasibility study intends to impartially and reasonably reveal the qualities and shortcomings of a current business or proposed adventure, openings, and dangers present in the indigenous habitat, the assets required to help though, and eventually the prospects for progress. Moreover, an impact assessment is related to a feasibility study, which evaluates the potential future effects of a development project on current projects and reasons. I think this is a critical phase in the SDLC, so I thought it would be good to read it carefully.
Hi Ryu, I agree that feasibility study evaluates the various aspects as a whole before starting a project. It is the scientific demonstration of the comprehensive technical and economic analysis of the proposed project before the decision through extensive research. As an important part of the preliminary work of a design project, it plays a very important role in the process.
The different changeover techniques were a good read. Changeover is an approach where a business decides to transfer from using an old system to a new system. As discussed in the CISA manual, there are three different changeover techniques— phased, parallel, and abrupt. Phased changeover is a technique where the new system is implemented one stage at a time. Parallel changeover is a technique where the new system runs simultaneously with the old system. Abrupt, or direct, changeover is an immediate replacement, meaning as soon as the new system is powered up, the old system is discontinued. Obviously, each changeover has its advantages and disadvantages. It is up to the business to select which changeover method will work best for the firm depending on the degree of risk.
Hi, Raisa:
Great post and you got me re-thinking about each changeover. I feel like choosing a changeover method is not only depending on the cost and resources but also how big is impact would be for the organization of failure happens. Overall, it depends on cost, the company’s core business, and the purpose of the new system. For example: If I recall correctly, Temple used parallel changeover method when switching from Blackboard to Canvas because that’s an important system for a university, and it would cause chaos for classes if the changeover failed.
After I read CISA Chapter 3.5 “Business Application Development” , the “Post Implementation Review” interested me most and I obtained a deep understanding of ” post implementation review”. The post project review is the last critical step in the project life cycle, as it allows an independent party to validate the success of the project and give confidence to the stakeholders that it has met the objectives it set out to achieve. the post implementation review helps us to:
-Identify the key project achievements and milestones
-Document any lessons learned for future projects
-Communicate its success to stakeholders
The best time to conduct a Post Implementation Review is between 1 and 6 months after a project has completed
CISA Chapter 3.5 “Business Application Development”, pp. 181-182
My points of interest are about the types of changeovers in the development/implementation phases of the lifecycle. This section covers the three types of changeovers, parallel, phased, and abrupt.
Parallel changeover: running both the old and new systems in parallel during implementation. Utilizing this technique, we’re able to use both systems during the period of overlap and slowly switching to the new system only after gaining confidence to use it.
Phased changeover: Using this technique, the old system will be broken into modules. Each module is slowly phased out into the newer system starting in chronological order. This changeover allows the system to be implemented in a preplanned, phased matter.
Abrupt changeover: This technique directly cuts off the old system at a cutoff date and time. The old system will be completely discontinued when the new system takes place.
In my opinion, the most ideal changeover technique would be to either using parallel or phased changeover. The abrupt changeover has the most risk and requires success in all four major steps of the changeover. Parallel changeover might not push to the acquisition of the new system because people will be inclined to stay with that they’re familiar with so implementation might be delayed. The phased changeover is the most logical technique because it’s an ongoing process of converting each module into the new system. This covers any risk that might be associated with directly cutting off the old system but still pushes people to become accustomed to the new system in an ongoing matter.
I agree. Change has to happen gradually and an abrupt changeover could shock your employees changing the application. Especially if the employees using the applications aren’t technically savvy. More importantly, if the customers are using the applications, an abrupt change could highly discourage customers and cause them to stop using the application or drastically slow down usage. A loss of users or a loss of usage could be very negative depending on what type of app it is.
Business application development is one of the most exciting important parts of the job. As an IS Auditor, your role is different than a PM’s or a Developer’s. An IS Auditor has the most advantages when the project is planned in a V-Model. For any Auditor, let alone an IS Auditor, it is most important for there to be a very formal structure and a V-Model Lifecycle is great for this. No matter what your position, business application development is the most interesting and exciting part for someone in an IT Role. In order for there to be a proposal for a business application, a new opportunity must arise first. This could be a new technology or an expansion in the business that requires more or more complex applications. Either way, business application development always comes hand-in-hand with a new business opportunity.
The interesting possibilities that it companies have invested lots of resources that help them streamline their key procedures, they include the development, acquiring, integration and the maintenance of the software system. These are the parts required for the life cycle process of any business application development. The process of implementing applications in business follows the project planning and processes of management as outlined. The development of application of business project has to start with an individual .When an individual applies the state of assessment of a proposed plan it is introduced as a result of more than one of the following circumstances: A fresh chance that relates to a fresh existing process of business, A problem that narrates to a current business process, the current technology problem, A fresh opportunity that will improve the company to take benefit of technology.
These circumstances are firmly combined with key business drivers. Key business drivers, in this setting, can be characterized as the qualities of a business work that drive the conduct and usage of that business capacity to accomplish the key business objectives of the organization.
Advantages of utilizing this methodology are that every single influenced gathering will have a typical and unblemished comprehension of the destinations and how they add to business support. Furthermore, clashing key business drivers and commonly subordinate key business drivers can be distinguished and settled in beginning periods of a SDLC venture.
Business application ventures ought to be started utilizing very much characterized systems or exercises as some portion of a characterized procedure to convey business needs to the executives. These techniques frequently require natty gritty documentation distinguishing the need or issue, indicating the ideal arrangement also, relating the potential advantages to the association. All inward and outer components influenced by the issue and their impact on the partnership ought to be distinguished.
A hazard in any product improvement venture is that the ultimate result may not meet all prerequisites. Issues because of interpretation blunders emerge when at first characterizing the necessities for interval items. The cascade model and variations of the model ordinarily include an actual existence cycle confirmation approach that guarantees that potential errors are redressed early and not exclusively amid conclusive acknowledgment testing.
165-183
165-183
One point is the user involvement in the design. After business process have been documented and it is understood how those processes might be executed in the new system, involvement of users during the design phase is limited. Given the technical discussion that usually occurs during a design review, end-user participation in the review of detailed design work products is normally not appropriate. However, developers should be able to explain how the software architecture will satisfy system requirements and outline the rationale for key design decisions. Choices of particular hardware and software configurations may have cost implications of which stakeholders need to be aware and control implications that are of interest to the auditors.
One thing of interest I took away from “CISA Chapter 3.5 “Business Application Development” would be the topic of “integrated resource management systems.” Within this topic, it mentioned that an integrated solutions implementation is a very large software acquisition project. For example, the acquisition and implementation of an ERP system impacts the approach the company does their business, which including the company’s entire control environment and technological direction. In terms of the scale of this, I think a thorough impact and risk assessment should be conducted.
Enterprise resource planning is a business process management software that allows an organization to use a system of integrated applications to manage the business and automate many back-office functions related to technology, services, and human resources.
Instead of several standalone databases with an endless inventory of disconnected spreadsheets. ERP systems bring order to the chaos so that all users—from the CEO to accounts payable clerks—create, store, and use the same data derived through common processes. With a secure and centralized data repository, everyone in the organization can be confident that data is correct, up to date, and complete. Data integrity is assured for every task performed throughout the organization, from a quarterly financial statement to a single outstanding receivables report, without deploying error-prone spreadsheets.
Also, this answer is question # 1.
Implementation is the process that turns strategies and plans into actions in order to accomplish strategic objectives and goals. The implementation process for business applications follows the project planning and management process as outlined previously. The business application development project begins when an individual application feasibility study is initiated as a result of one or more situations. All of these situations are tightly coupled with key business drives. Which in this context, can be defined as the attributes of a business function that drive the behavior and implementation of that business function to achieve the strategic business goals of the company. Therefore, all critical business objects have to be translated into key business SDLC project. So that general requirement will be expressed in scorecard form, which allows objective evidence to be collected in order to measure the business value of an application and to prioritize requirements.
After thoroughly reading through Section 5 of Domain 3 in the CISA textbook, which primarily focused on the topic of “Business Application Development”, I started to take note of the application development models described that we also talked about in class on various occasions. Among those application development models were the waterfall model and the verification-validation model, which the text notes as being able to help companies mitigate their risks of not meeting business requirements set during earlier phases of development. The textbook goes on to further explain that implementing these models mitigates risk by providing points in the software development life cycle where testing and analysis occur so as to catch and correct errors in the early stages of development. The textbook also mentioned one of the more thorough and time consuming forms of testing for software which I was not very familiar with, that being unit testing. After reading about unit testing briefly in the textbook, I dug around the internet a little bit for a little more information regarding it and found that it is considered the most thorough because it is the most micro-oriented form of testing where you analyze very small sections of the code right after completion.
Hi Jordan,
Great observations and take-away from this chapter. It is indeed there are many models of testing your application. Testing is the step before applying to the real system so this is very important. And you mentioned that there are many forms of software, which is what I found also interesting from this Chapter’s reading. Many softwares are focusing on one main utility but vary at the micro level.
My key take-away from CISA Chapter 3.5 “Business Application Development” is Phase 6 of SDLC which is “Post Implementation Review”. Post-Implementation Review (PIR) is conducted after completing a project. Its purpose is to evaluate whether project objectives were met, to determine how effectively the project was run, to learn lessons for the future, and to ensure that the organization gets the greatest possible benefit from the project. PIR helps in validating that all components of the SDLC are present in the completed project documentation:
– The project plan is updated and finalized
– Requirements were documented, approved and finalized
– Program design were documented
– Test plans, procedures and results were documented
– Issues lists were maintained
– An implementation plan was finalized
Under this section of CISA manual, it emphasizes that IS auditor performing this review should be independent of the system development process and therefore, IS auditors who were involved in consulting of project development should not perform this review.
Hello,
Reading through what you found as the most interesting part of the CISA textbook module 3 segment 5 on “Business Application Development” truly helped paint a more vivid picture of points that the CISA textbook was trying to get across. I appreciate you putting in the effort to list what is often validated in regards to finalized documentation during the post-implementation review, as it shows that you have developed an appropriate understanding and can even help explain concepts to others. I also appreciate the small note included at the end which emphasized how important it is that the IS auditors performing the reviews are different from those who were consulted during the development process, for independence’s sake.
The interesting thing that I took away from CISA chapter 3.5 is phased changeover. Phased changeover brake the old system into deliverable modules and then phased each old module by replacing the newer relevant system. This is a cheaper way compare with the parallel, and it’s also a less risky way compare with Abrupt changeover. However, there are some risks that may exist such as resources challenges from both the IT side and the operation side, an extension of the project life cycle to cover two systems, and change management for the ongoing replacement of the old system by deliverable modules. I would consider that change management would be the riskiest.
Good points, Shuyue! I found the changeover techniques interesting too. Deciding which changeover technique will work best for a particular organization depends on the type of changeover and level of risk for that organization. Touching on disadvantages for each technique— abrupt, or direct, changeover carries the most risk because if something goes wrong, reverting back to the old system is usually next to impossible. The disadvantage for phased changeover is that the process takes a while to complete because the phases need to be implemented one by one. Lastly, a disadvantage for parallel changeover is that since the two systems are running simultaneously, there are higher costs associated with this particular technique.
Hi Shuyue, I agree as well. The phased changeover is the most logical changeover technique to me as well because it has the least risk and cost compared to the abrupt and parallel changeover. Running both systems during parallel changeover will incur an unnecessary cost for the company. There are many risks with the abrupt changeover, and there are too many security areas that can go wrong with directly cutting off and switching to a new system.
I find that the phase 6 of business application development, postimplementation review is also important within the whole process. As the book mentions, project implement team and appropriate end users, or an independent group not associated with project implementation can perform a postimplementation review after all the design finished. The postimplementation review should include various aspects including assess the adequacy of the system, evaluate the projected cost benefits or ROI measurements, develop recommendations and plan for implementation and assess the development project process. These reviews are the bottom line against any design vulnerabilities through the participation of others who with different perspectives, to find problems that implementation team fail to pay attention to. The postimplementation reviews should make sure all the goals are met, or provide valuable guidance if there are any problems. The object of the review is the current status and output, and the purpose of the review is to ensure the final correct output will be delivered.
Hi Yuqing, You did a great job by emphasing on independence of users performing post implementation review. This is a key point to consider as an IS auditor. Segregation of duties need to be verified during the post implementation review testing and we need to ascertain that no users from development, testing or implementation team be part of post implementation review.
There is often a difference of opinion as to who should perform the Post-Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to work, how to fix problems, etc.
There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review.
A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. The project team might then reconvene to consider that input and also to examine how to generate further value from the solution.
Hi Yuqing, I think you are right. I also believe that the post-implementation review a critical part. Post-implementation review is the last step in your project cycle and usually involves an independent party, which can act more objectively in making their determinations about how the project was run. I think it will make the whole process complete.
Hi yuqing, I like your opinion. You pointed out how can the project benefits from post-implementation and the critical steps to complete post-implementation review. To Sum up,The post implementation review is the last critical step in the project life cycle and it is very important. It needs to ensure all project make their goals and identify project achievements and what went right or weaknesses and what went wrong.
Certification is a process by which an assessor organization performs a comprehensive assessment against a standard of management and operational and technical controls in an information system. The assessor examines the level of compliance in meeting certain requirements such as standards, policies, procedures, work instructions and guidelines requirements made in support of accreditation. The goal is to determine the extent to which controls are implemented correctly, operating as intended and pricing the desired outcome with respect to meeting the system’s security requirements. The results of a certification are sued to reassess the risk and update the system security plan, thus providing the factual basis for an authorizing official to render an accreditation decision.
Hi Yuan,
Great comments! Thank you for sharing the definition of certification with us. I agree with you that the goal of this is to implement the controls effectively.
CISA Manual Chapter 3.5 “Business Application Development” p. 181-182 had several sections with one section drawling most of my attention — Phase 6 — Postimplementation Review (PIR). The post implementation review very important and is conducted to ensure that the system meets design and development specifications as well as control requirements. One interesting aspect of the PIR is that the information to be analyzed is collected during prior analysis phases. For instance, during the feasibility and design phases, a lot of the requirements and specifications to be analysed will first be mentioned here. In terms of who will be involved, members for the development team, end users, and business analysts should be included in the review. Aside from the IT Auditor — a third part group outside of the project should evaluate the functionality of the system to remove any confirmation bias.
Great point. Postimplementation Review is very important.
For example, after completing a year-long project to establish a new quality management process for your organization, you want to make sure that what you set out to do was actually achieved. Your objective wasn’t to simply deliver a process – but rather, to deliver the process that addresses the specific business need you intended to meet. This is the real measure of success.
Nice points- I found these interesting as well. Involving an outside party allows for us to know if the system is truly user friendly since they would be conducting an objective review, rather than solely basing functionality off the opinion of developers or others who have been involved throughout the SDLC and are familiar with the system.
I found the section integrated resource management systems interesting. Lots of organizations are shifting from separate groups of interrelated applications to a fully integrated corporation solution. Such solutions are often marketed as ERP solutions. ERP solutions commercial application such as SAP, Oracle Financials or SSG are all pretty useful tools for corporations.
The business opts to change business processes to suit the industry standard as dictated by the software solution. The whole idea of ERP system shows the strength of integrated as a whole should be better than separated standalone applications.
Advantages of ERP:
1. Complete visibility into all the important processes, across various departments of an organization (especially for senior management personnel).
2. Automatic and coherent workflow from one department/function to another, to ensure a smooth transition and quicker completion of processes. This also ensures that all the inter-departmental activities are properly tracked and none of them is ‘missed out’.
3. A unified and single reporting system to analyze the statistics/status etc. in real-time, across all functions/departments.
4. Since same (ERP) software is now used across all departments, individual departments having to buy and maintain their own software systems is no longer necessary.
Postimplementation reviews are interesting in that there are two approaches: one being an internal review from the project development team and end users, and the second being a review from an independent source that was unassociated with the project itself, such as auditors. We can appreciate both of these system review approaches, as the developers and end users are typically concerned with usability, while independent auditors are mostly concerned with the system control features during the development and implementation phases. Effectively, it’s important to note that in order for these reviews to be successful, the information that is reviewed should be identified during the feasibility study and design phase, with progress being documented as the project moves forward. It’s interesting that the end of the project still relies on the early stages of project development, not only in a technical aspect, fact being that documentation is vital from the beginning in order for those involved to successfully complete each task.
The interesting I took away from chapter 3.5 is the feasibility study in traditional SDLC phases. As mentioned in the book, the traditional SDLC approach is made up of a number of distinct phases each with a defined set of activities and outcomes. A feasibility study intends to impartially and reasonably reveal the qualities and shortcomings of a current business or proposed adventure, openings, and dangers present in the indigenous habitat, the assets required to help though, and eventually the prospects for progress. Moreover, an impact assessment is related to a feasibility study, which evaluates the potential future effects of a development project on current projects and reasons. I think this is a critical phase in the SDLC, so I thought it would be good to read it carefully.
Hi Ryu, I agree that feasibility study evaluates the various aspects as a whole before starting a project. It is the scientific demonstration of the comprehensive technical and economic analysis of the proposed project before the decision through extensive research. As an important part of the preliminary work of a design project, it plays a very important role in the process.
The different changeover techniques were a good read. Changeover is an approach where a business decides to transfer from using an old system to a new system. As discussed in the CISA manual, there are three different changeover techniques— phased, parallel, and abrupt. Phased changeover is a technique where the new system is implemented one stage at a time. Parallel changeover is a technique where the new system runs simultaneously with the old system. Abrupt, or direct, changeover is an immediate replacement, meaning as soon as the new system is powered up, the old system is discontinued. Obviously, each changeover has its advantages and disadvantages. It is up to the business to select which changeover method will work best for the firm depending on the degree of risk.
Hi, Raisa:
Great post and you got me re-thinking about each changeover. I feel like choosing a changeover method is not only depending on the cost and resources but also how big is impact would be for the organization of failure happens. Overall, it depends on cost, the company’s core business, and the purpose of the new system. For example: If I recall correctly, Temple used parallel changeover method when switching from Blackboard to Canvas because that’s an important system for a university, and it would cause chaos for classes if the changeover failed.
After I read CISA Chapter 3.5 “Business Application Development” , the “Post Implementation Review” interested me most and I obtained a deep understanding of ” post implementation review”. The post project review is the last critical step in the project life cycle, as it allows an independent party to validate the success of the project and give confidence to the stakeholders that it has met the objectives it set out to achieve. the post implementation review helps us to:
-Identify the key project achievements and milestones
-Document any lessons learned for future projects
-Communicate its success to stakeholders
The best time to conduct a Post Implementation Review is between 1 and 6 months after a project has completed
CISA Chapter 3.5 “Business Application Development”, pp. 181-182
My points of interest are about the types of changeovers in the development/implementation phases of the lifecycle. This section covers the three types of changeovers, parallel, phased, and abrupt.
Parallel changeover: running both the old and new systems in parallel during implementation. Utilizing this technique, we’re able to use both systems during the period of overlap and slowly switching to the new system only after gaining confidence to use it.
Phased changeover: Using this technique, the old system will be broken into modules. Each module is slowly phased out into the newer system starting in chronological order. This changeover allows the system to be implemented in a preplanned, phased matter.
Abrupt changeover: This technique directly cuts off the old system at a cutoff date and time. The old system will be completely discontinued when the new system takes place.
In my opinion, the most ideal changeover technique would be to either using parallel or phased changeover. The abrupt changeover has the most risk and requires success in all four major steps of the changeover. Parallel changeover might not push to the acquisition of the new system because people will be inclined to stay with that they’re familiar with so implementation might be delayed. The phased changeover is the most logical technique because it’s an ongoing process of converting each module into the new system. This covers any risk that might be associated with directly cutting off the old system but still pushes people to become accustomed to the new system in an ongoing matter.
I agree. Change has to happen gradually and an abrupt changeover could shock your employees changing the application. Especially if the employees using the applications aren’t technically savvy. More importantly, if the customers are using the applications, an abrupt change could highly discourage customers and cause them to stop using the application or drastically slow down usage. A loss of users or a loss of usage could be very negative depending on what type of app it is.
Business application development is one of the most exciting important parts of the job. As an IS Auditor, your role is different than a PM’s or a Developer’s. An IS Auditor has the most advantages when the project is planned in a V-Model. For any Auditor, let alone an IS Auditor, it is most important for there to be a very formal structure and a V-Model Lifecycle is great for this. No matter what your position, business application development is the most interesting and exciting part for someone in an IT Role. In order for there to be a proposal for a business application, a new opportunity must arise first. This could be a new technology or an expansion in the business that requires more or more complex applications. Either way, business application development always comes hand-in-hand with a new business opportunity.