bsa methodology plan

BSA Methodology Plan 1

BSA Methodology Plan

Brook-Todd Crenshaw, Leon Kilpatrick, and Nick Spoon

July 1, 2011

University of Phoenix


Identification and Description of a Business Situation

One of the most critical steps in project management is the identification and description

of a business process that needs to be analyzed. This step is important as it can affect the whole

identification and solution selection process including the maintainability of the project after

completion. Based on a request from the Senior Marketing/Sales Manager, Riordan’s marketing

and sales databases are not communicating with each other. Management wants to correct this

problem by implementing a solution that allow for the transference of data from one database to

another. The development team must conduct an analysis of the current database structure and

determine the feasibility of enabling data transfer between the two.

It is recommended that Riordan considers a range of options from general office

applications to off-the-shelf or in house developed database systems. Basic functionality should

include a system with ordering, invoicing, and marketing utility capabilities. By providing the

company with database integration of the two systems, Riordan will be better able to manage

marketing and sales data, ultimately leading to improved operational effectiveness.

Database integration will help customers save time and money, while also guaranteeing

data accuracy and timely report generation. This will help to reduce process expenditures and

allow the company to react to customer’s needs more quickly, which will have a positive impact

on the bottom line.

Important Tools: Analysis Checklist

Throughout the Software Development Life Cycle (SDLC), a valuable way to keep track

of all processes and tasks is to use an analysis checklist. Analysis checklists aid in business

systems for high-level detailed analysis. The checklist, however, is traditionally used to ensure

that a series of processes or tasks for project complete in a timely fashion. The analysis checklist


utilized by Team A will include a list of all processes and tasks to be completed, the time and

date needed for completion, whether or not the task was completed on-time, and a field for

recommendations for completion and comments by those specifically carrying out a particular

task or process. Proper use of the analysis checklist will ensure that Team A’s project is

completed successfully and within scope.

Figure 1: Checklist

Analysis Checklist

Evaluation Points Time/DateYes No On-time Comments/Recommendations

Process or Task 1

Process or Task 2

Process or Task 3

Project Management Success Factors

While the ultimate goal facing a project manager is to see out a thorough and successful

project from start to finish, traditionally following a path similar to what is found in the SDLC,

there are a few more success factors that are critical in project management. The first will be to

see how open Riordan is to the proposed changes and how interactive they are with Team A in

creating a bright vision of Riordan’s future operations.


It is important to ensure that everyone is committed and engaged in the vision and tasks

at hand. All avenues of communication must remain open, encouraging all involved to vocalize

any concerns, ideas, dislikes, and other important customer requirements to add to a mutually

successful venture for both Riordan and the PM.

After Team A’s thorough analysis of the current database systems, the team will be able

to deliver clear ideas for process improvement and refinement to Riordan. This vision will be

used to create a visual that will clearly captivate Riordan into embracing the changes while

showcasing something they aren’t seeing at the time. As the accomplished writer Jonathan Swift

once wrote, “vision is the art of seeing things invisible.” Combining the vision with a concise

path of execution and accompanying weekly deliverables provides a solid foundation for

company acceptance.

The final success factors revolve around the ever present bottom line. Ensuring that the

resources used and the total cost for the project is kept as low as possible is vital. The second

success factor would be that all timelines are respected and all communication regarding the

project and possibly hindrances to the timelines are openly voiced, keeping all parties in the

know. The final factor and most important is ensuring that Riordan is happy with the results.

This will be properly examined when Team A returns for the post-implementation audit.

Organization and Where to Start

In business system analysis knowing where to start is crucial for the entire process to

succeed. To provide Riordan with a complete and accurate analysis and a solution to their

existing database incompatibility problem, the following steps may be taken.

1. The entire picture must be taken into account, meaning focus cannot be on the

databases alone. The analysis team must look at how these databases affect each department in


Riordan as well as what effect a change might cause. Not looking at this overall picture may

leave some departments running more efficiently while others may find their workload doubled.

2. Look for and note any areas that have the slightest possibility of affecting the analysis

process. Hidden or unknown factors exist and must be exposed and documented to prevent them

from creating a negative influence in the analysis process and final recommendation.

3. Categorize existing products by similarity and compatibility. Knowing what

applications are used and how they can interact with each other can provide cost savings.

4. Schedules, both of employee use of the systems as well as batch jobs or other functions

that may take place during off normal business hours must be known. Tragedy may occur if

processing is interrupted of a critical system at one of the plants because of an

unknown/undocumented function on the system.

5. Fully understand why the management of Riordan wants to change their current

business process and application use. Not knowing what the management wants and why they

want it may leave management with the exact problems they are asking the team to resolve.

6. Prepare a deliverables form. The form needs to be prepped for use and should contain

a list of all deliverables and the timeline (both short and long-term) for those deliverables. This

provides the management of Riordan with confidence that they will see progress as well as

accurate timelines.

7. Use the team’s standard analysis tracking system to provide the management of

Riordan with an accurate and up-to-date documentation, discussion information, meeting

minutes, and other pertinent information for the process.

8. Maintain a clean system for the analysis. Team A will not allow for items that have

been dismissed from the project to collect or mingle with the current functional information.


Keeping the project work area clean of out-of-date or no longer needed items also helps maintain

an organized process flow.

9. Be prepared to plan ahead. Though a deliverable has a start and end, this does not

mean that the team performing the analysis should not be ready to start on the next portion of the

project immediately after a portion is complete.

The analysis project will start by focusing on the needs of the management of Riordan.

The analysis team will need to document the current planned direction of the company and what

changes they wish to alter the company into a new direction. By collecting this information, the

analysis team can provide recommendations to the management of Riordan to alter the direction

of the company into a new and more profitable direction. The focus portion of the analysis will

include a high level design of the new business architecture; what the managers of Riordan want

to achieve. Feasibility studies will ensure that the envisioned architecture is a fit for Riordan and

can be collected through systems analysis, focus groups, employee interviews and surveys and

employee functional task analysis. These steps will provide the starting point for the

recommendations from the analysis team.

Methodology: A Description

To initiate improvements to Riordan’s existing sales and marketing DB systems, Team A

has chosen to implement a Rapid Application Development (RAD) methodology. While

traditionally, the RAD approach has a minor pitfall of minimal planning for a more protocol-

based approach, Team A understands that the previous research and keys for success are in place

but simply need reexamined and the ultimate goals need realigned. The alternate allure for

utilizing the RAD approach is the favorable use of prototyping. In developing something of this

nature with an emphasis on improving internal database communication, the best approach


would involve prototypes in a pseudo real-time environment to ensure communication is present,

concise, and firing on all cylinders.

Expectations of the RAD Approach

Team A’s expectations deriving from the use of the RAD methodology are simple;

develop two re-worked marketing and sales databases able to communicate with each other in

real-time on a day-to-day operational level. Combining this with a revamped Radio Frequency

Identification (RFID) scanning system, the inventory database will consistently be updated and

inserted in the proposed re-vamped database communication matrix in real-time and ensure all

sales are genuine and improve Riordan’s overall net present value (NPV). By extensively

prototyping with existing hardware, the team can create the environment for which to test these

modifications without a tremendous overhead cost. Combining that with a minimal software

venture for RFID scanning purposes and a new SQL-based database approach, the overall cost of

the proposed ventures will keep Riordan rather pleased both from an operational and an

economic standpoint.

Key Deliverables for the RAD Approach

The deliverables for an approach like this should match the project itself in that they are

concise and rather straightforward to arrive at the ultimate goal as soon as possible. The

deliverables for this service request are to:

Compile previous analysis and cross-reference that with a concise analysis of how the

databases are currently synced.

Examine the hardware/software and the process as it stands to understand where the

communication is.


Shadow/Question management from site-to-site to understand when this started to occur,

why, repercussions because of this, etc.

Trace all applicable network topologies to validate/strengthen the previous two

deliverables and ensure that communication will be possible with current technology

Develop retooled SQL-based database prototypes for sales, marketing, and inventory

purposes

Establish dummy server to simulate a real-time environment and begin work on internal

database communications

Test, test, and test to ensure communication is accurate and continuous prior to “live”

launch

From here it will be a matter of taking the prototypes and translating them into the real

environment for the final “live” launch.

Steps in Rad in Relation to the PLC

As traditionally utilized in a software development approach, Team A feels this is simply

going to be perfect in comprehensively re-working the databases in a SQL approach to

emphasize communication in real-time and strengthen the software. The manner in which the

RAD approach is executed will adhere closely to what is traditionally found within the PLC. In

beginning with the initiation phase, there will be less emphasis here as Team A will be going on

previous analysis combined with a lighter amount of analysis simply to gather the necessary

information regarding the current state of these databases in the environment they are currently

working within. The planning stage will be the next logical approach in which current

topologies and frameworks are examined to ensure the SQL-based approach will work and

communication can be improved in the team’s current proposed manner.


The emphasis will shift to developing comprehensive prototypes that will fix the

communication errors currently occurring. In testing in a real-time environment, on isolated

servers, Team A will ensure that the three servers will be communicating with each other while

taking dummy orders to simulate Riordan’s day-to-day operations. Once these key changes are

functional in the simulated environment, the move will shift to the implementation/execution

phase. The prototypes will be moved to the real-time environment and the planned solution will

officially be implemented. Once testing as thoroughly as possible, the databases will be cleared

to go live, and the focus will shift on areas affected, support, and moving toward updating any

and all Risk Analysis matrices currently in place.

Tools for Implementing the RAD Approach

Through the use of the JAD technique, Team A will quickly be able to determine the

system requirements for the revamped SQL-based databases. This will be vital when Team A

begins shadowing and questioning each respective management team from site-to-site. The

prototype will serve as a point of reference in pitching the proposals and showcasing the changes

that Team A will be attempting to make, which will also be the fastest way to showcase the

improvement in communication and ensure everything is operational prior to moving to the

“live” environment. The construction phase is vital in prototype development and computer-

aided software engineering (CASE) in conjunction with an application generator will assist the

Team in tailoring the SQL databases to the needs of Riordan.

Applicable Prior Research

The merging, connecting and synchronizing of different databases is easier today than

it was just 10 years ago. Today’s systems offer Application Programming Interfaces (API’s) that

allow different systems to communicate with each other, facilitating any type of collaborative


process between two or more systems. Unfortunately, the Riordan database systems are old

systems and API’s are not available. The systems will need specialized connectors to allow

communication and interpretation of data components between the systems. Applicable prior

research for methods to accomplish this task using Rapid Application Development is un-

available. However, other case studies might aid in the process such as that of the Agile Project

(Heap, 2011).

Unrealistic Project Components

Components just like expectations must be defined at the start of the project. These

components are:

1. Executive or Management Summary – This document outlines the problem and

proposed solution. This document is designed to familiarize the reader with the business process

at it exists and as proposed.

2. The Product – This portion of the document provides the information about what is

being offered as a service.

3. The Competition – This portion identifies the competitors to Riordan, what their

known processes are and how they are competing against Riordan in the area under analysis.

4. Operations – A very important part of the process describing the roll out of the new

system for Riordan and how the roll out will affect operations.

5. The Management - Documenting what the expected experience will be for those in

charge of operations for the new system.

6. Personnel – Documenting what the expected experience will be for those involved in

working with the output of the new system and how the new system affects other areas.


An unrealistic component would be marketing, as the system may affect marketing of

Riordan but the analysis does not and therefore is not included.

Ignorance of Corporate Culture

A complete study must be made of the Riordan business culture. The step about to be

taken by the company could cause a hyper growth situation in the company due to increased

demand and sales by use of the new system. The current business culture could doom that

company to failure if it is not prepared to make rapid changes if needed.

Bowett (2011) emphasized that:

At certain times in a business’ development and growth it becomes apparent that the

business culture is completely inappropriate for the future. Often this realization comes

when a new management team is appointed to take a business forward into a new stage,

especially if had become clear that the previous management team wasn’t up to the job.

So the business culture has to be changed. This is extremely difficult. People don’t like

change. However daft the old system, many people will cling to the old system because it

is known territory and they have spent years learning how to manipulate it to their own

advantage; they feel comfortable with it (p.).

Logistics and Time Lines

Logistics will play into the process but only marginally. The Riordan systems currently

communicate through mixed networking technologies. Location of the databases to be tied

together will most likely not affect the process; however, there is the possibility that the

networking technology will need to be upgraded to support the needed throughput and data

transfer. Time estimates for the implementation of the Riordan solution will be estimated after a

full evaluation of the current database systems are complete. At that point a complete time line


will be built based on expected deliverable projections. Estimates earlier in the process would be

a best guess situation, as lack of information about the systems being addressed, the size of the

databases and the content of the databases does not allow for an accurate description or

projection.

Impact Due to Type of Industry

System impact will be determined after the analysis is complete. Based on the current

lack of functionality of the system, the estimate of impact to the business will be at the level of

inconvenience. At this level, some features and functions may not be available during normal

operations during the initiation of the project yet no long-term outages are expected. Complete

testing will be accomplished prior to initiation of the changes to minimize the chance of long-

term impact.

Economics

The current system is incapable of providing Riordan with an efficient method to use the

data stored in the database systems. Though the cost of analysis and implementation of the

recommended upgrade will require a high expenditure, the loss of revenue for continuing with

the current system will be much higher. Many businesses refuse to upgrade systems during a

down economy and in most cases are looking for ways to cut costs. Initially, there will be

expenditure but the cost savings once the economy returns will provide Riordan with an

advantage over their competitors. This advantage will leave Riordan’s competitors scrambling

to catch up and could take several years to accomplish.

Conflicting Goals and Priorities

It is essential that the database project be organized in such a way that conflicting goals

and priorities among group members are minimized. “Studies have shown that group


cohesiveness has been found to be more productive than individual capabilities and is necessary

to keep conflicts at a minimum” (Lakhanpal, 1993). Project member roles should be clearly

defined and all team members should be held accountable for their tasks. Establishing these

expectations early in the development process is a good way in which to mitigate potential

conflict on a project. Developing and adopting a project charter that lists the projects objectives

and rules is a good way to obtain universal buy-in of the project and avoid conflict. The charter

should describe things such as project teams work hours, staff meeting schedules,

communication methods, while also forecasting other priorities and their possible impact on the

project.

Non-IS Influences

One possible non-IS influence in regards to the RAD methodology for Riordan will be

managing user expectations as Riordan employs a large, well informed, computer savvy staff.

Due to the use of RAD tools and techniques that can improve the speed and quality of systems

development, user expectations of what is possible may dramatically change due to their

knowledge of IT concepts. Staffing the project is another consideration that can have a major

influence on the success of the project. This will include determining how many people will need

to be assigned to the project, matching skill levels with project needs, and motivating the team.

Lastly, economic influences which are concerned with the financial risk associated with the

project and organizational considerations that deal with how well the new system will be

accepted and incorporated into ongoing operations will be of significant influence.

Resource Limits

Riordan is currently in a position where resources are being utilized on numerous service

requests. In order to properly align resources, managers need to have a clear understanding of

how those resources are being allocated. It is foreseeable that managers may need to redirect


funds and staff from one project to another in order to meets project deadlines. Additional

resources may need to be outsourced, especially in light of the fact that the current infrastructure

is being revamped and there is a true need to invest in training programs for all the newly

proposed systems. Proper and timely allocation of resources will show that management is

serious about its revamping intentions. Employees will exhibit less uncertainty about

management’s commitment to the new system if they observe that resources are being

committed to support it.

Tool and Talent Availability or (Non)-Availability

Most RAD-based methodologies employ special techniques and computer tools in order

to speed up the analysis, design and implementation stages of the SDLC. Joint application

design (JAD) sessions, CASE tools, fourth-generation languages (e.g., Visual Basic) that speed

up and simplify programming task, and code generators are some of the tools that may need to be

utilized. It will be necessary for management to ensure that the proper tools and talent is in place

to ensure proper utilization of these tools and resources. This may include tool acquisition and

hiring new talent on a temporary basis or outsourcing to specialists in the field. Conventional

wisdom says that the more programmers and specialists that are involved on a project, the longer

it will take to build and implement the system. This is attributed to the fact that as the size of the

team increases, so does the need for coordination of activities. More time required for

coordination translates to less time for development. Best practices call for the smallest possible

team with each team member possessing multiple IT talents.

Distribution of Power and Ongoing Sponsors

The biggest resource in controlling the distribution of power and power struggles that

stem from management policies. Policies need to be implemented that will clearly define the


management structure in regards to the new system, as well as defining the new work processes

and by whom those processes should be performed. Goal setting, consistent enforcement of

policies and guidelines on how organizational members are rewarded and promoted will all

contribute to a fair understanding of the distribution of power.

In order for the new system to be successfully adopted, management policies will need to

support its adoption. New systems typically bring about change to old business processes by

enabling new ways to accomplish old tasks. On-going sponsor support is garnered through

policies that define the rules of managing the new system. Therefore it is essential that the

rewards and rules be revised and published to reflect the new opportunities that the new system

affords. SOP’s are great for defining proper behavior, as it is easier to gain sponsor support for a

well-defined and documented business process or system

Mitigation of Risk: Cost/Benefit

Riordan is certainly in a position right now where the cost needs to align directly with the

proposed changes and technological progression in order to ensure there is not an erroneous

amount of spending and all the current issues are addressed. There is a serious need for the cost

to be justified by the benefits, both immediate and long-term. In using a smaller scaled PERT

chart, Team A will be able to essentially showcase a revamped network diagram that will

comfortably introduce the revamped database. This will also allow Riordan to see how exactly

Team A is changing the schema of the network to allow for simultaneous and real-time

communication between the two current and reworked databases, as well as the third new

database. Doing this in conjunction with the Critical Path Method, or CPM, will properly

showcase exactly how time is spent within processes and on what exactly.


The majority of the cost will come in man-hours spent reworking the existing databases

and shifting the network focus from the current server structure to properly and logically

allowing the communication from server to server and database to database. In taking what is

currently in-house and making it more complete while also utilizing existing hardware to house

this information transportation, Riordan can be assured that a majority of the overhead costs are

kept to a minimum.

By essentially measuring everything in terms of monetary value, Team A will showcase

the benefits vastly outweighing the costs. While the risks of the ventures outlined are relatively

nominal, the true benefit is intervening at a time when the database systems can stand to see

structure and communication bolstered. The positives that will arise from this will be adequately

justified within the PERT, CPM, and cost-utility analysis that occurs and will help to showcase

the real cost factor simply being time and man-hours. In prototyping the proposed environment,

Riordan will get the chance to understand whether the changes are the direction they are looking

for and whether or not Team A’s proposals are the best direction for the company.

Net Present Value

In not having databases properly communicating with one another, purchasing

and processing are thrown off. Incoming orders are going off of an assumption of materials in-

house rather than a solid understanding of inventory. Unless communication is done through e-

mails and phone calls, each independent site cannot be sure of what inventory and processing is

being done at other sites and the sales team is at a real disadvantage when on the go. In properly

prototyping the databases and internal communication Team A is proposing, the sales team will

be able to see updates in real-time. In improving the stagnant and hypothetical nature of day-to-


day transactions, Riordan can be sure of what kind of business the company is doing on a daily

basis and, in turn, raise the overall net present value vastly over a six month time span.

Least Cost Alternative

Prior to deciding the RAD approach would be the most financially-conscious and

beneficial option for Team A to pursue, there were other options examined. In taking a waterfall

approach, Riordan would be looking at a process that would essentially trickle down from one

database to another. The hypothetical improvements would be something that would have to be

isolated to one database at a time and then introduced separately. After the database

environment was deemed stable, the team would then focus on effectively joining the two

networks for a cohesive communication highway between both databases. The timing and cost

were something that was not ultimately going to be respected and the introduction of exterior

hardware/vendors would have been pursued. In taking the time to properly weight the costs and

benefits of multiple approaches, Team A has justly concluded the RAD approach has been found

to have the lowest cost, therefore making it the least costly alternative available for Riordan at

this moment.

Cost/Economic Analysis

The economic impacts of the RAD approach, more specifically how prototyping will

ensure a solid venture, are certain to bolster Riordan’s presence within the industry. While it is

one thing to improve the NPV of a company, the long-standing goal of any successful company

is to remain that way (stability) for many years (longevity). In doing so, the company will rise to

a certain level of prominence within the industry and lead rather than figure out ways to fit in or

simply follow. The economic ramifications extend far past the cost of the entire operation and

will ultimately impact the day-to-day operations and how Riordan operates each quarter.


Decision Evaluation Matrix

A decision evaluation matrix is a rather powerful tool that Team A is consulting in

conjunction with this request response. In doing this, the team will be able to formulate multiple

decisions as to what might be a suitable option in response to the service request and, in turn,

will have multiple items to consider in a sort of “pros versus cons” kind of debate. The best

manner in balancing this is to consult the decision evaluation matrix that will allow the team to

properly weigh the options before ultimately opting for the RAD route and all of the

accompanying work that will follow within the parameters of this methodology.

The example matrix (figure 2) showcases a concise version of the elaborate planning and

discussion that went into this decision and the accompanying justifications or cons that worked

in conjunction with each approach. A number system is assigned to each level based on a 1 – 5

scale with 1 being the lowest in desirability, 3 being mid-level, and 5 being ideal.

Figure 2: Decision Evaluation Matrix Sample

Install Time Low Cost BigBenefit?

OverallSupport

Option 1 - RAD 5 5 3 5

Option 2 - Waterfall

1 3 3 1

Option 3 - Phased 1 1 3 3

Option 4 – Agile Development

5 3 3 1

Risk Analysis

Risk is something that must be examined prior to deciding to go with any option, as the

methodology and accompanying proposals must be feasible and within a reasonable risk

assessment prior to exploring. By utilizing a facilitated risk analysis process or FRAP, Team A

can thoroughly take a look at the process as it stands and understand the day-to-day risks that are

associated with it currently, while also examining each approach outlined within the decision


evaluation matrix to comprehensively understand the best approach for Riordan. In

understanding the current risk factors such as cost, current network strength, and annual budgets,

the team will be given the tools necessary to understand what is economically feasible and what

simply will not work. Combining this with the current IT infrastructure at Riordan, the flaws and

holes become apparent and the risks begin to show themselves.

Tangible and Intangible Benefits

The tangible benefits of this plan will provide monetary savings through faster processing

capability as well as increased income generation because of those faster processes. Monetary

savings will also be realized from the lack of having to make major changes to the current

Riordan system. By upgrading instead of replacing the existing database systems, the life cycle

of these systems will effectively be extended far beyond the typical replacement life cycle. This

will result in large monetary savings to Riordan while other monetary savings will be found

through the familiarity of the current data. This savings is realized because employees using the

system will be familiar with the data which shifts the focus of the training for employee paid

time from learning a completely new dataset to operation of the new system. This will cut

training time and ramp up the new system faster than if the data were completely new or in an

unfamiliar format. The savings of what would be additional time will show in monetary savings

both of employee pay as well as in faster use of the system, which equates to faster processing of

orders and more sales to the company. Other savings will be found in the ability of Riordan to

decrease its inventory, removing much stock obsolescence, and potentially expanding the system

into a complete automated order/payment system.

The intangible benefits include time savings to employees, allowing for time to be better

spent on other projects or tasks. Along with time savings comes a higher level of fulfillment by


employees since the tasks using the new system will be easier and faster. This will lead to

increased productivity and better performance for Riordan employees. With increased

productivity, the potential for Riordan to expand its vendor list and provide for a wider market

increases. This will allow the company to compete for more contracts through better processing,

making bids more accurate and competitive in the industry. Reports will become more accurate

and the lowering of risk will also be achieved with this new system.

Feasibility of the Technology, Human Resources, Financial and Organizational Impact

Ultimately, Riordan will be concerned with three things, cost in relation to the bottom

line, whether the service request is addressed to the company’s specifications, and finally, the

feasibility of all changes and how they pertain to the company. In terms of technology, the

feasibility will be rather high, as the team will utilize in house technology to power the new

databases. Examining the network topologies and revising the layout will showcase how the

capabilities were currently present, a restructuring and realigning simply needed to occur in order

to kick start the internal communication. The biggest cost expenditure would come in

purchasing a new and improved RFID system, which would technically be optional upon

pitching the need to Riordan.

Human resources will be unaffected by any of the proposed changes. HR will simply

have to ensure that the employees are able to adhere to the changes from site-to-site with relative

ease and are not put off by any of the changes. Other than simply focusing on morale and overall

attitude, feasibility as it pertains to HR will be high. The financial feasibility will certainly be

manageable and will only stand to improve the company’s NPV, day-to-day sales, and revenue

generated from marketing and cross-promotions. By bolstering internal database

communications, Riordan will see an emphasis on process refinement and an improvement in


annual fiscal returns. In reworking the current network topologies and placing an emphasis on

internal communications, the organizational structure will see a rather large impact.

Recommendations

The recommendation is to follow the standard implementation practices for RAD

deployment. The first step is the pre-implementation stage, which includes the documentation of

existing issues and requirements of the new system. This is followed by a new solution designed

to eliminate as many of the existing issues as possible and within the expected budget for the

project. Each department will need to be completely studied to provide a list of what

departments will receive the modified system and in what order. This analysis must take into

account that Riordan cannot shut down operations while the upgrade is taking place. The plan

will require strong management cooperation as well as support. Without the management

component, this project will have little success of providing Riordan with the benefits outlined in

the prior portion of this analysis. Test teams must be assembled to run through daily business

scenarios to find and correct as many issues as possible before going live. A comprehensive

training program must be created to ramp up the acceptance and use of the new system as

quickly as possible. The familiarity this program will provide also will provide quicker response

to issues that may have made it past the testing phase. Post go-live training should be included to

answer any questions that may remain during the rapid transition from the old methods to the

new and the new system.

Procedures for Handoff to Development and Implementation Teams

Once the Database Integration project is combined into a system proposal, it should be

presented for approval as to whether the project should be initiated or not. If approved, it enters


project management, at which time the project manager should create a project plan which

describes the procedures that the Database Integration project team will utilize to develop the

system. The plan should include the project staffing requirements as well as the techniques that

will be used to control and direct the project through completion. Most of the strategic decisions

about the Database Integration System should be accomplished at some point in the analysis

phase, while design strategy should establish the intent to develop the system in house using

RAD technologies. Basic architecture design should address how the system will be integrated

into the infrastructure already employed at Riordan.

Specifications of the interface design should reveal the manner in which users will

navigate through the system as well as the reports and forms that will be utilized. This should be

followed by the development of the database and system files that determine what and where the

system data will be stored. These combined deliverables will allow Team A to develop a system

specification that describes each program that will need to be implemented as well as what each

program will need to accomplish. The system specification is then handed to the development

and implementation teams for implementation.

Schedule for Post-Implementation Audit

A post-implementation audit (PIA) is a top down assessment of all the benefits resulting from

the implementation of a new or revised information system and the efficiency of the project

management processes in installing it. The PIA is an important tool to collect things discovered,

identify what went right, what went wrong and the underlying reasons for each. This information

can prove to be invaluable to Riordan when addressing what may go right or wrong in future

implementations. Steps must be taken long in advance of the post-implementation audit to


document the business case by outlining the expected benefits of the project, expenditures,

expected ROI, and how long it will take for the ROI to be realized.

While there has been great debate over who should perform the PIA, general consensus is

that the most common groups should include one or more of the following:

Members of the project implementation team from IT

Members of the project implementation team from both IT and the business

Representatives from a company’s internal audit department (Levinson, 2003).

After identifying those to be included on the audit team a PIA meeting should be held in

order to categorize the steps needed to perform the audit. This should include:

Reviewing the business case

Scope analysis/change order comparison

User satisfaction evaluations

Implementation team members evaluations of the implementation

System and control tests that examine data quality

Integration transaction tests to make sure integration is performing as expected

Finance Department review of the system’s profitability.

The results of the audit should then be compared to the business case to determine if the business

objectives have been achieved.

Riordan Manufacturing clearly sees an area for improvement within their current

databases. In examining the current system and developing revamped databases with an

emphasis on database-to-database communication, Team A will ensure that all respective pieces

are working together to produce results and inventory in real-time and bolster sales. By utilizing

a RAD approach, Riordan will be able to see the comprehensive changes Team A is proposing in


a pseudo real-time environment and get a more hands-on approach to ensure that the changes fit

the company’s day-to-day needs and current business model. In allowing Riordan to be a vital

part of the process, Team A will ensure that all customer requirements are met while improving

internal communication and, in turn, generating a stronger internal process that will bolster sales

and ensure Riordan remains an industry leader for years to come.


References

Bowett, R. (n.d.). Organisation - Introduction to Corporate Culture. tutor2u. Retrieved from

http://tutor2u.net/business/organisation/culture_intro.htm

Heap, T. (2011). A Case Study: A Business Analyst on an Agile Project. Bridging the

Gap. Retrieved from http://www.bridging-the-gap.com/agile-project-business-analyst-case-

study/

Lakhanpal, B. (1993). Understanding the Factors Influencing the Performance of Software

Development Groups: An Exploratory Group-Level Analysis. Information and

Software Technology, 35( 8), 468-473.

Levinson, M. (2003). How to Conduct Post-Implementation Audits. CIO.com. Retrieved from

http://www.cio.com/article/29817/How_to_Conduct_Post_Implementation_Audits?page

=3&taxonomyId=3154

http://www.cio.com/article/29817/How_to_Conduct_Post_Implementation_Audits?page

http://www.bridging-the-gap.com/agile-project-business-analyst-case-study/

http://www.bridging-the-gap.com/agile-project-business-analyst-case-study/

http://tutor2u.net/business/organisation/culture_intro.htm

bsa methodology plan

Documents