SDLC MIS Reporting

Get *ALL* 100+ Editable Word, Visio, HTML & Project Source Documents (500+ Files) Totaling 1000+ Printed Pages for Only $497 - Buy I.T. Now!

SDLC

*DOWNLOAD NOW $497

SOP 1030: MIS Reporting

Objective:

The objective of this Standard Operating Procedure (SOP) is to document the procedure for generating reports for SDLC’s business departments.

Scope:

This procedure establishes the criteria for accepting, approving, tracking, and developing MIS report requests. This procedure should be used for all requests for information from the MIS databases. These requests could be one-time requests for MIS data or requests that need to be automated and delivered on a daily, weekly, or monthly schedule.

Owner:

Operations

Sections:

i	Definitions
1	Process Flow Diagrams
2	Roles and Responsibilities
3	Metrics
4	Procedure Activities
5	Forms
6	Exceptions
7	Tools/Software/Technology Used
8	Attachments

Related Standard Operating Procedures:

1005

Release Planning

Get "IT"
ScalabilITy - ReliabilITy
FlexibilITy - AgilITy
LongevITy - QualITy
.doc .xls .ppt .mpp .vsd .htm EdITable; Policies, Processes, Procedures, Projects Tasks, Diagrams, Forms & Files.
DOWNLOAD
Satisfaction Guaranteed.

-->

SDLC Standard Operating Procedures:

SDLC Framework:

SDLC Gates:

SDLC Roles and Responsibilities:

SDLC Forms:

SDLC Templates:

SOP 1030 - MIS Reporting Definitions

Term	Definition/Description
*Program/Project Management* .	The systematic execution of a System Development Life Cycle (SDLC) for a release or projects that have significant impact on an organization’s service delivery. This procedure oversees the SDLC execution; thus, it relies heavily on defined procedure activities and acceptance criteria for inputs and outputs Note: Every unit within SDLC interacts with Program/Project Management. Every release of new and enhanced features and functionality requires the commitment and effort from all departments.
*Project Manager*	The focal point throughout a project who ensures that the responsible party has completed with quality and comply with defined acceptance criteria. The *Project Manager* also acts as the conduit for communicating the progress of the project and decisions made throughout the process to the *Project Sponsor, Contracting Organization, and the Performing Organization*.
*Program Management*	Addresses oversight for a group of projects. *Program Managers* shoulder the responsible for the successful completion of program objectives by supporting and developing project staff. Reporting at this level provides *Executive Management* with the information necessary to make informed decisions and execute actions that optimize benefits to the organization.
*Program Manager*	The tactical manager who facilitates, monitors and communicates the progress and issues in implementing the strategic objectives of an approved program. The *Program Manager* works cross-functionally to develop the blueprint that integrates multiple release deliverables that enhance the program’s portfolio.
*PMO*	The *PMO* is the organization that consolidates all project plans and reports the status to executive management. Impacts from individual projects can be seen from an organizational perspective and responded to rapidly. The *PMO* is where project and program standards, procedures, policies and reporting are established.
*Business Gate*	defined milestone in a project lifecycle when specific requirements must be met in order to make or validate business decisions relating to the project.
*Lock-Down*	The milestone in a project schedule achieved when agreement exists between the Performing Organizations and the Contracting Organizations for the delivery of a defined project scope of work within a defined schedule at a defined cost.
*Management Phase Review*	An event associated with selected business gates where specific decisions concerning the project are made by appropriate levels of management. Deviations in deliverables or timeframe are handled by convening the Gate 6 Review Board. This group will make any decisions concerning scope, cost, and schedule tradeoffs. These business gates are: G-11: Project Strategy Lock-Down G-10: Requirements Scope Lock-Down G-6: Project Lock-Down G-4: Begin Validation G-2: Begin FOA G-0: General Availability
SDLC Business Gates	The foundation is Program/Project Management in the SDLC Business Gates. This Systems Development Life Cycle (SDLC) begins at project initiation and moves through deployment to the production environment.
*Phase*	A collection of logically related project activities, usually culminating in the completion of a major deliverable. The conclusion of a project phase is generally marked by a review of both key deliverables and project performance in order to determine if the project should continue into its next phase as defined or with modifications or be terminated and to detect and correct errors cost effectively.
*Program*	A defined set of projects containing common dependencies, and/or resources and/or objectives overseen by a Program Manager
*Project*	A temporary endeavour undertaken to create a unique product or service. A project has a defined scope of work (unique product or service), a time constraint within which the project objectives must be completed (temporary) and a cost constraint. In the context of SDLC, a project may be one of: an individual feature a collection of features making a release a collection of product releases making up a portfolio a new product development
*System Development Life Cycle (SDLC)*	A predictable series of phases through which a new information system progresses from conception to implementation. All of the activities involved with creating and operating an information system, from the planning phase and/or the initial concept to the point at which the system is installed in a production environment. The major phases are Release Planning, Definition (Requirements and Specifications), Development, Test (Validation), and Deployment.

1. Process Flow Diagrams

Site Monitoring and Problem Management Overview

Click Image to Enlarge

2. Roles and Responsibilities

*Role*	*Responsibility*
Report Requestor	The organization or individual that contracts with the MIS department to develop reports. For the purpose of this document, the requestor is defined as any internal SDLC department or personnel. The requestor is responsible for clearly defining the report request by completely filling out the Report Request Form. All requests for reports from external sources must be funneled through a requestor. The MIS Department will not accept requests directly from external sources such as clients and ISPs.
Designated Group Representative	The Sales, Finance and Engineering groups will each establish a designated group representative that acts as the initial funnel for all MIS report requests. These designated group representatives will screen all requests and then forward them on to the Marketing Analyst.
Marketing Analyst (Product)	The Marketing Analyst acts as the second funnel for all report requests. The Marketing Analyst collects all the requests from the various internal SDLC departments, checks for completeness, analyses business justification, and prioritizes all report requests prior to distributing them to the MIS team. The Marketing Analyst will only accept requests from the designated group representative of each of the internal SDLC departments.
MIS Team	The MIS Team will be responsible for logging and tracking report requests, as well as designing, coding, testing, and delivering the final report. The MIS Team is responsible for the accuracy of the report and the data in the MIS databases/tables.
MIS Manager	The MIS manager will assign a designated team member to log the initial report requests into the Report Request Tracking Tool. The MIS Manager will also assign a MIS developer to each request.

3. Metrics

The following data should be captured throughout this procedure to help estimate MIS report requests and to help measure the effectiveness of this procedure:

Priority (Critical, High, Medium, Low)
Actual Start Date
Actual Completion Date
Actual Report Run Time
Actual Report Development Time

4. Procedure Activities

Gate/Activity

Description

Click Image to Enlarge

Requestor:

Initiate Report Request

All report requests must be generated by one the following “internal” SDLC Departments:

Sales
Finance
Engineering

If an external source wishes to request a report, the request must first be directed to one of the internal departments mentioned above. In order to request a report, the requestor must fill out a Report Request Form (See Appendix A) and forward it via e-mail to their designated group representative.

Group Manager:

Select Group Representative

Each internal group defined in step 4.1 is responsible for naming a designated group representative to collect all requests within their respective group. This designated group representative reviews the Report Request Form for completeness, before forwarding it (via email) to the Marketing Analyst.

Requestor:

Fill-out Report Request Form

Regardless of the requestor’s job title, a Report Request Form must be filled out before any work begins. It is imperative that all SDLC staff, including upper management, follows this procedure and uses all required forms.

Marketing Analyst:

Review and Prioritize Requests

The Marketing Analyst acts as the central collection point or funnel for all report requests. The Marketing Analyst collects all the requests from the various internal SDLC departments, checks for completeness, analyses business justification, and prioritises all report requests prior to distributing them to the MIS team. The Marketing Analyst is empowered to reject requests if the Report Request Form is incomplete or there does not appear to be sufficient business justification for the request. The Marketing Analyst has up to two business days to approve or reject a Report Request Form.

Marketing Analyst:

Approve Request

If the Report Request Form is approved, it is e-mailed to the MIS Team.

Marketing Analyst:

Reject Request

If the Report Request Form is rejected, the Marketing Analyst will send the form back to the designated group representative with an explanation of why the request was rejected.

Marketing Analyst:

Log and Document Report Requests

Upon receipt of the Report Request Form from the Marketing Analyst, a designated MIS Team Member logs the requests into the Report Request Tracking Tool. The following information needs to be captured in the tool:

Report name
Description
Business Need / Justification
Requestor name
Requested Due date
User Defined Priority (Critical, High, Medium, Low)
Request Status (Received, Rejected, Request Approved, Feasibility Approved, Design Complete, Code/Test Complete, Report delivered, Report Accepted )
Rejection Reason

Initially, the request status is logged as "received" by the designated MIS Team Member. If the Report Request Form is incomplete, the form will be e-mailed back to the Marketing Analyst with a reason for the rejection. The request status will be set to “rejected” and the rejection reason should be entered into the Report Request Tracking Tool.

MIS Manager:

Approve Request for Research

All “received “Report Request Forms need to be evaluated within two business days by the MIS Manager upon receipt. If the MIS Manager knows that the report cannot be satisfied because the data requested is unavailable, the MIS Manager rejects the report request.

If the request is approved, the MIS Team Member updates the Report Request Tracking Tool by changing the request status to “request approved”. It should be noted here that the report request might still be rejected later in this procedure based on the outcome of further detailed analysis.

MIS Manager:

Reject Request for Research

The assigned MIS Team Member or MIS Manager updates the Report Request Tracking Tool by changing the request status to “rejected” and entering the rejection reason (i.e. – Data not available).
The MIS Manager notifies the Marketing Analyst and requestor immediately of the request status. The reason the request was rejected needs to be clearly stated in the communication back to the Marketing Analyst and requestor.

Requestor

If a request is rejected, the requestor may follow up by requesting the data be added as part of a future system release, so it is available for future reporting. A Service Request Form should be completed and forwarded to the appropriate group as defined in the Release Planning Procedure (SOP 1005)

MIS Manager:

Produce List of Approved Requests

On a weekly basis, the MIS Manager should produce a list of all the “approved” requests ranked by priority and distribute it to the Marketing Analyst. It is the shared responsibility of the MIS Manager and Marketing Analyst to review all approved requests in the queue and re-evaluate priorities.

MIS Manager:

Assign Development Resources

The MIS Manager is responsible for assigning work to an MIS Developer. All work is assigned based on the agreed upon priorities.

MIS Developer:

Report Research Feasibility Research

The assigned MIS Developer analyses the report request. In some cases, this analysis may take a couple of days to determine whether or not the request can be satisfied. The MIS Developer reviews the request to determine whether or not the data requested is in the MIS database and is available to satisfy the report request.

Request can be approved

The MIS Developer updates the Report Request Tracking Tool by changing the request status to “feasibility approved” and an estimated completion date.

The MIS Developer notifies the Marketing Analyst and the requestor of the estimated completion date. If applicable, the MIS Developer communicates to the requestor if the request will be added to the automated reporting process.

Request cannot be approved

The assigned MIS Team Member or MIS Manager updates the Report Request Tracking Tool by changing the request status to “rejected” and entering the rejection reason (i.e. – Data not available). The MIS Manager notifies the Marketing Analyst and the requestor immediately of the request status. The reason the request was rejected needs to be clearly stated in the communication back to the Marketing Analyst and the requestor.

Requestor

The requestor may follow up by requesting the data be added as part of a future system release, so it is available for future reporting. A Service Request Form should be completed and forwarded to the appropriate group as defined in the Release Planning Procedure (SOP 1005)

MIS Manager

If the report needs to be added to the automated report process, the MIS Manager reviews the request with the MIS DBA. The MIS Manager must approve all changes to the automated reporting process.

MIS Developer and Requestor:

Design Report

The assigned MIS Developer is responsible for designing the report. Before coding is started, the MIS Developer must confirm the design with the requestor. This can be done formally by producing specifications or informally by a quick e-mail. The important thing is attaining sign-off from the requestor (by either signing the specifications or via e-mail) for the work to be performed and the criteria by which the requestor will accept the report.

Upon receiving confirmation of the design by the requestor,

The MIS Developer updates the Report Request Tracking Tool by changing the request status to “design complete”.

MIS Developer:

Develop and Test Report

The assigned MIS Developer codes the report as per the design. The MIS Developer tests the report by verifying the information on the report agrees with the data in the MIS database. The MIS Developer prior to distribution must test all reports. The MIS Team is responsible for the accuracy of the report and the data in the databases.

The MIS Developer updates the Report Request Tracking Tool by changing the request status to “code/test complete”.

MIS Manager:

Add Report to Automated Process (Optional)

This step is optional and should only be performed for report requests that were approved to be added to the automated process by the MIS Manager.

If the report needs to be added to the automated reporting process, the assigned MIS Developer is responsible for ensuring the report is added and that it is tested and accepted before moving the report to production.

MIS Developer:

Deliver Report

The MIS Developer delivers the report to the requestor and updates the Report Request Tracking Tool by changing the request status to “report delivered” and the actual completion date for the report. The time the report took to run and to develop will also be captured. This information will be used to develop metrics for estimating the time it will take to complete similar requests.

Requestor:

Accept Report

The requestor reviews the report and either approves or rejects it. The requestor verifies that the final report deliverable agrees with the “confirmed design”. If the report does not match the design it is rejected and sent back to the assigned MIS Developer to fix any problems or inconsistencies. The requestor needs to accept or reject the report within two business days of receipt.

If the report is accepted, the Report Request Tracking Tool is updated by the MIS Developer to reflect that the request status is “report accepted”.

MIS Manager:

Update and Track Status of Reports

It is the responsibility of the MIS Manager to ensure that all report requests are entered, updated, and tracked through each activity. It is also the MIS Manager’s responsibility to communicate the status of each requested report to the Marketing Analyst and the requestor in a timely fashion.

Every Friday, the Marketing Analyst will communicate all delivered report requests for the week to the internal SDLC groups. An e-mail distribution list will be used to facilitate this communication.

5. Forms