Common Criteria for Deciding Whether to Buy or Build

Common criteria for deciding whether to buy or build a software solution would be to take a look at the System Development Life Cycle; Planning, Analysis, Design, and Implementation. Planning or initiation include a business problem, request for proposal, request for quote, and proposal/quote ie. first go/no go decision. Analysis or logistics of implementation include business requirements, technical requirements, and data requirements, and GAP analysis which helps a company compare actual performance with potential performance. Design includes logical/physical, technical specs, process flow/data flow, system architecture, data design, screen layouts, and navigation map/flow. Once these criteria are examined and the complexity is determined, a decision can then be made to buy or build a software solution. Implementation is turning it into a working system that has been tested and put into use including documentation, training procedures, support capabilities, and associated updates. A manager’s selection for off-the-shelf software can be established by deciding if the criteria of cost, functionality, vendor support, viability of vendor, flexibility, documentation, response time, and ease of installation will be greater and a smoother transition than producing an in-house software solution. The two most important aspects of purchasing an off-the-shelf software are vendor support and vendor viability. If a manager chose to produce in-house software, the support is a constant in that the programmers who created the software are available at any time, and know the ‘in’s and out’s of the software’, whereas if there is no vendor support from the purchased software you are taking a gamble which may prove unwise, and the credibility of the manager is no longer. Cost, functionality, flexibility, and documentation are criteria that depends primarily on the specific situation, ie. budget, and needs. Discuss the four phases involved in managing a project. Compare and contrast these phases with the SDLC. Explain any differences. Managing projects of all shapes and sizes requires a fluid, nonlinear framework that has applications across all essential elements of project planning. The four-phase process that suggests how to allow for readjustment between the phases are initiate, plan, execute, and evaluate. Initiate, this first project management phase, the preliminary work is done to clarify the problem or opportunity and how a solution would look. All interested parties are consulted and the project scope – what is in and what is out – is clarified as well as initial costs and timelines. Plan, determines whether the proposed project will be of real benefit to the organization. If it is, the project is approved and more detailed planning starts. Business benefits, project objectives, requirements, governance, scope and project management methods are agreed. The Project Manager draws up the detailed project schedule and task and budget allocations. Execute, project stakeholders are interviewed to ascertain the detailed requirements, possible solutions are discussed and decided upon. Next, the solution is designed, built and finally implemented. Project management activities in this phase also include managing the project budget and schedule, reporting project progress, communicating with stakeholders and responding to project risks, issues and proposed changes. Evaluate, The purpose of this final phase is to determine whether the project was a success and what was learned can be gleaned and applied to future projects ie. , did the project deliver on time, within budget and to scope and quality requirements? Comparing the four phases in managing a project; initiate, plan, execute, evaluate with the SDLC phases; Plan, Analysis, Design and Implement one will see many cross similarities; each describing approaches to a variety of tasks or activities that take place during the process. After each phase is finished, it proceeds to the next one; reviews may occur before moving to the next phase which allows for the possibility of changes. Reviews may also be employed to ensure that the phase is indeed complete; and is ready to progress to the next phase. Explain the three primary project identification and selection phase activities. Who should make the decisions about project approval in a business organization? What information is important to the decision? Project identification and selection consists of three primary activities: identifying potential development projects, classifying and ranking projects, and selecting projects for development. Identifying potential development projects is a process that can be performed by a key member in top management, a steering committee, the head of a requesting committee, the development group or IS manager. Projects by top management reflect broader needs of the organization since there is an understanding of overall business. Projects identified by a top management or steering committee are referred to as coming from a top-down source. Projects designed by individual mangers or the IS group are more focused on the needs rather than a broader scope; projects stemming from managers, or business units are referred to as a bottom-up source. Top-down and bottom-up initiatives are used in identifying and selecting projects, it will vary on the scope and needs of the project. Classifying and ranking projects can be performed by top management, a steering committee, business units, or the IS development group. The project requirements will vary by the organization administering it, one group may choose to meet monthly, whereas another chooses to meet quarterly. Meetings typically consist of reviewing ongoing projects as well as new project requests. Selecting projects for development is the final activity in the project identification and selection phase. Since the criteria for a project can change at any time, numerous factors must be considered when selecting a project; perceived needs of the organization, existing systems and ongoing projects, resource availability, evaluation criteria, current business conditions, and perspectives of the decision makers. Projects can be accepted or rejected which means funding is allocated or the project will no longer be considered for development. A project can be returned to the original requesters who are told to develop or purchase the requested system themselves. Also, the requesters of a project may be asked to modify or resubmit their request after making suggested changes or clarifications. Due to the process of incremental commitment a selected project does not necessarily result in a working product. After each subsequent SDLC activity, the members of the project team will reassess the project. This reassessment will entail a more detailed understanding of the system’s costs, benefits, and risks to determine if the project was a worthy as it was thought to be. How should a project team determine system requirements? What are common sources of requirements? What are the limitations for each? In addition, discuss four types of documents that would be helpful in determining future system requirements. During requirements and determination analysts gather information on what the system should do from as many sources as possible. Sources include users of the current system, reports, forms, and procedures. All of the requirements are carefully documented and made ready for structuring. Structuring includes taking the system requirements during determination and ordering them into tables, diagrams, and other formats that make it easier to translate into technical systems specifications. Some examples of requirement determination include, impertinence, impartiality, relaxing of constraints, attention to details, and reframing. Impertinence is questioning everything. Are all transactions processed the same way? Could anyone be charged something other than standard price? Will employees be allowed or encouraged to work for more than one department? Impartiality is finding the best solution to a business problem or opportunity. All issues must be considered to try to find the best organizational solution. Relaxing of constraints, assuming anything is possible and eliminates the infeasible. Organizations change and all policies and rules should be evaluated. Attention to details, everything must fit into place. If one element is out of place, the whole system will fail. Reframing, looking at the process in a new way. It is easy to assume the project will be the same or similar, but this assumption can lead to failed systems. Constantly challenging yourself will prove beneficial in this process. Specific examples to be gathered at the requirements determination phase are, the business objectives that drive what and how work is done, the information people need to do their jobs, the data handled within the organization to support the jobs, when, how, and by whom or what the data are moved, transformed and stored, the sequence and other dependencies among different data-handling activities, the rules governing how data are handled and processed, policies and guidelines that describe the nature of the business, the market, and the environment in which it operates, and key events affecting data values and when these events occur. It is important that the scope of the system not become to large and expansive that analysis paralysis not occur, this can become costly and time consuming, and can lead to an abundance of work. To deter this from happening analysts must focus on the system in need not the system in place. Documents that are helpful in determining future system requirements are administering written questionnaires ie. surveys to discover issues and requirements, business documents ie. iscover reported issues, policies, rules, and concrete examples, and conducting written interviews with open-ended and close-ended questions. Also directly observing users an give a more objective and accurate review. Read the following online article and discuss two ways to justify IT budgets. How would you explain your IT budget to your CFO? To justify an IT budget is to provide a quality ROI on any new initiative. If the CFO can’t understand the needs of various departments then the only way to their pocketboo k is to present them with a bottom line return on their investment. In the case of procuring an IT budget, executives are often less than forthcoming because of the lack of information they receive from department heads. CEO’s respond most favorably to requests for IT budgets which are cost justified with a simple ROI business case. The business case needs to specifically show how potential costs associated with liability, may be minimized by implementing a sound IT infrastructure. The potential liabilities, such as loss of production and/or loss of reputation are translated into actual dollars in the ROI. A good business case or a good investment analysis will also measure the probabilities of different ROI outcomes. An investment analysis is the examination and assessment of economic and market trends, earnings prospects, earnings ratios, and various other indicators and factors to determine suitable investment strategies. Explaining the IT budget to the CFO you should first examine core needs ie. bandwidth, Internet, phone and staff, and plan to manage them on a minimal investment. Explore reducing excess capacity in the server room, renegotiate vendor contracts and rethink software licenses. Assuring the CFO that you have taken all necessary steps in limiting the IT budget will prove that you have taken all necessary steps to ensure a minimal budget while providing an the required IT services. Revisit past assumptions, you may have a contract that replaces hardware every two years, which could be an unnecessary budget item, and could in return be replaced every four years. Show the CFO how improvements have helped customer experience and saved money. Give him/her a friendly remember that not investing in things that could be and important aspect to IT when the economy turns around can come back to bite you. IT’s value is determined by the relationship between what the organization will pay, ie. cost, and what it will get back ie. benefits. The larger the amount of benefit in relation to cost, the greater the value of the IT project.