Government App Sharing
|
|
||||||||||||||
| Home | Free Meeting Place for Government App Sharing |
|||||||||||||
|
Risk Management Discussion Ideas for Mitigating Risk During Software and Hardware UpdatesIntroductionThere are many opportunities to minimize risk in software implementation and hardware installation. The role of risk mitigation becomes more important the larger the project is, or the more impact it has. This paper explores methods to minimize risk and recommends establishing a Risk Management Policy. ScopeRisk herein pertains to risk during software migration to production or hardware installation. Related methodologies are PMBOK (which defines traditional risk management) and software development methodology, SDLC (such as Agile, Waterfall, Spiral, etc.). This paper addresses specialized migration planning concerns beyond PMBOK and SDLC and does not supersede them. Stakeholder list and policy impactStakeholders: IT, PMO, business clients, change control board, ITIL Impact to current policy:
MethodologyThe general methodology involves configuring project time schedules to separate out project components in a way that optimizes vetting in a stepwise manner. Example: A component is being added to the mainframe that consists of a new table and new programming code. Instead of moving them to production at the same time for client use after testing in the test environment, move the table to production first and test it alone for a day or less without the programming code (test with ad hoc queries and joins that only programmers can see). This may unearth a host of potential problems such as permissions authorization, size, data-type constraints, compatibility with the OS, etc., but will not interfere with clients using the rest of the system. All of the above problems could have appeared on production-implementation day, throwing the implementation schedule off and causing clients to wait in standby mode during their scheduled testing time. With this methodology, these problems are already out of the way before implementation day. The idea is to break a project down to the highest number of components that have vetting value and test them early during non-critical times, including migrations to production, to reduce risk as much as possible. Analysis is required to:
What is new in this methodology:
Treatment of the production environment as an extension of the testing environment is important because production may have patches, data, security and other things in its environment that the test environment doesn't, that can affect the success of migrated components that worked correctly in the test environment. Early stakeholder identification is important. For example, suppose Team A plans a major change that affects Team B. If Team B is brought in early in the conception stage, they may be able to recommend a project design that avoids funneling all change implementation into one instant switchover from the old to the new system. Otherwise, Team B loses control of their time schedule and is compelled to migrate everything into production at once with a very small tolerance window for errors. The goal is to avoid introducing unnecessary errors and staff stress by intelligently configuring implementation time lines. This will produce a much wider tolerance window. Another example, if a field length is increased for Team A, Team B may be able to increase their field length early and fully test in the test environment, then production environment, because additional field length testing doesn't require that actual Team A data be in production yet. This can remove substantial pressure off of Team B because the amount of time they have to implement has been stretched out by good design planning early on. Below is an example of identifying the Legal Department as a stakeholder and bringing them into implementation planning early. Example 3: Assume that two regulatory agencies, Board A and Board B, will be merged into one agency. Here is a broad outline of possible risk management steps (besides standard PMBOK):
Harmonization could include:
Centralizing data could include: Replacing both agencies' tables with a single centralized table before programming code is changed so that problems are isolated to data, identified early, and not combined with other programming problems on implementation day. Switch-enabling programming code could include: Writing programming code in a way that allows concurrent implementation of both new and old systems in production. The choice of which one runs, or if both run simultaneously, can be determined by a conditional, programmatic switch based on a "yes", "no" or "both" value in a data field. If, for example, there are many users, this provides a good back-out method to revert to the old system with minimal down time. In the above example, component vetting in production has been spread out to non-critical times. Had everything been migrated into production at one time, many problems occurring at the same time would make implementation much more complicated. The above is only a general description. The data centralization step might be omitted so that the entire implementation would involve concurrent systems. Case by case analysis is required to determine variables such as: "Is redundant data entry required to implement two concurrent systems?" Risk Management PolicyTo bring about implementation-design collaboration of different teams,
it is recommended that a Risk Management Policy be established.
Implementation planThe risk management policy and methodology themselves should be implemented in a stepwise manner with prototype testing before mandatory use. Performance Measurement and Process ImprovementEach risk management effort would be measured by a follow-up survey of stakeholders affected by the methodology (Appendix B). Use history and recommendations to improve the methodology or policy would be recorded. Recommendations would be logged onto the risk management forum. Responsible parties
Future Expansion And Enterprise Architecture ConsiderationsAnalysis after implementation would indicate if there is value to further expansion of risk management policy. The policy is currently written with the narrowest scope, but the idea can appllied across many business processes. 1. The project scope can remain narrow, limited to software and hardware
installation. ConclusionThe goal of the methodology is to implement change in a way that no longer becomes an "all or nothing" panic-filled project requiring hundreds of components and variables to work in perfection at implementation time. The premise is that there are many hidden opportunities to reduce risk that are revealed when this methodology is used. Except for early stakeholder notification, these recommendations should be tailored to the individual project without rigid compliance when common sense dictates that low return on investment would result. Designing for implementation will bring benefits of less downtime, greater client satisfaction and will simplify troubleshooting on complex hardware installations and software updates. Much of this can be achieved by simply rearranging the order that components are introduced into production and tested. As an additional benefit, over time, each team could establish a body of best practices, some of which would result from use of these guidelines. Much of this methodology can apply to any business undertaking and should be freely borrowed. Appendix ARisk Management Checklist
Appendix BRisk Management Survey
|
