RFP Guide

For

Service: Entrepreneurship , Uruguay

How to Develop and Manage RFPs for ICT

 

 

 

 

 

Executive Summary

An RFP (Request for Proposals), also known as a bid, is a very effective tool for contracting and outsourcing services in the public as well as private sectors around the globe. This document, generated by the Computer Aided Strategic Planner (STRAP) after an interview, is intended to help government officials develop an RFP for ICT services (i.e., eservices). It consists of the following sections:

Section 1: Background Information about RFPs with some general guidelines for developing and managing RFPs

Section 2: Sample RFP Templates with links to sample RFPs and also a link to the STRAP Sample RFP for downloading

Section 3: Problem Specific RFP that shows the main results generated by STRAP. These results are very problem and project specific and form the Technical Content (or Terms of Reference) in the RFP. This is the most important part and differentiates one RFP from another. :

How to Use This Document

  • Step 1: Read Section 1 for general information
  • Step 2: Review Section 2 to select an RFP template that suits you, if you do not already have an RFP template for your organization.
  • Step 3: Carefully read the contents of Section 3 to develop an understanding of all the information captured by STRAP.
  • Step 4: Based on the type of RFP (i.e., outsource only a small part versus everything), you can build a customized RFP for your situation by extracting the needed portions from Section 3 and customizing the technical content from the information shown in Section 3. If needed, you can invoke the STRAP RFP Generator to create a draft customized RFP to get you started. .

The following diagram illustrates the overall process used by STRAP to produce the RFP Guide and also the Customized RFP:

  • An RFP Guide is generated automatically at the end of STRAP processing. This Guide contains detailed technical specifications generated by STRAP based on the user interview.
  • A Customized RFP is generated optionally by the user, i.e., a user can take the info in the RFP Guide and build an RFP manually or use the RFP Generator to build a Customized RFP.
  • The RFP is generated based on some outsourcing options that could be based on an Outsourcing Advisor that allows the users to examine and evaluate different outsourcing options such as outsource everything, outsource project management only, outsource integration bus, etc.

 

 

 

SECTION 1: Overview and Background Information about RFPs

An RFP is a commonly used document for soliciting submittal of proposals in response to a scope of work. RFPs are used as a basic tool for contracting goods or services.

An RFP must be a clear, concise and consistent document that provides enough information to the prospective vendors but avoid unnecessary details. It must provide the following pieces of information:

  • The issuing company
  • The organizational and technical environment in which the goods or services will be used
  • The specific goods and services needed (Technical Specifications/Terms of Reference)
  • Vendor qualifications
  • Timelines
  • Submission and evaluation process
  • Others

Many guidelines for developing RFPs are available on the Internet. Here are a couple of examples:

 

 

 

Section 2: Sample RFP Templates

STRAP RFP Template

Many companies sell RFP templates for different types of packages for a fee. See, for example, http://rfp.technologyevaluation.com/store.asp

View STRAP RFP Technical Specifications

RFP_TemplateDownload STRAP RFP Technical Specifications

.

 

 

Section 3: Technical Specification (Terms of Reference)

NOTE: The following specification shows the main results generated by STRAP. These results are very problem and project specific and form the Technical Content (or Terms of Reference) in the RFP. Carefully read the following report to develop an understanding of all the information that can be used to develop and manage an RFP.

This information is not in a format to be sent out for bidding. It covers many aspects of the service being provided.

Depending on the type of outsourcing (everything versus only one part), some of the information will be important to the RFP providers and the other to the RFP responders.

You need to build a customized RFP from the following information for your situation by extracting the needed portions and customizing the technical content from the information.

For help in creating a customized RFP, please invoke the STRAP RFP Generator it will create a draft customized RFP to get you started. . .

TECHNICAL SPECIFICATIONS

 

Service:

entrpurug
( Entrepreneurship )

Govt.:

urgu1
( Uruguay )

 

 

 

 

 

 


A. Business process description

 

Contents

  1. List and detailed description of the processes
  2. Information for the documents that will be exchanged: list of data, data type, type of existing DBs, validation requirements, ...
  3. Roles and responsibilites
  4. Identification and authorization of the actors in the process
  5. Signatures (required and available)

Others as needed

 

 

Plan Generated Document for

Economic Development in Uruguay

Service Name: Entrepreneurship

Contents

  1. Government Model
  2. Service Model
  3. Suggested Solutions
  4. Management Considerations
  5. General Integration Issues
  6. Country/Region Specific Details
  7. Additional Details

 

The report contains a mixture of generic and customized information. Specifically:

  • Generic information (common best practices, e.g., security) that enforces common standards and practices. It is represented with Navy Blue Heading Bars.
  • Service specific (e.g., healthcare versus education) information to address the unique problems for the type of service. It is represented with Marooned Heading Bars.
  • Situation specific (wireless versus wired, large versus small system) based on interviews. It is also represented with Marooned Heading Bars because many service and situation specific information items are intermixed.
  • Country/Region specific (e.g., Belgium vs. Brazil) suggestions based on rules triggered by country/region specific factors. It is represented with Yellow Heading Bars.

 

 

1.

Government Model

 

Reliance on Web

No use of Web(Paper-based systems)

Mobility Reliance

No use of mobile computing

E-Readiness Index

0.5848

Networked Readiness Index (WEF)

3.81

Desired use in Services

Few Services

Time Horizon

One year

Population (2008) millions

3.35

GDP (Billion USD) (2008)

23.09

Landline Phone Connections per 100 citizens

28.64

Cellular Subscriptions per 100 citizens

104.73

Internet Users per 100 citizens

40.01

Broadband Users per 100 citizens

7.3

 

Industry Pattern

Owned by Government

Regulated by Government

Mode of Operation

Education

No

Yes

Centralized

e-Government Services

Yes

Yes

Centralized

Law Enforcement and Public Safety

Yes

Yes

Centralized

Utilities

No

Yes

Centralized

Healthcare

No

Yes

Centralized

Transportation

No

Yes

Centralized

ICT

No

Yes

Centralized

Agriculture

No

Yes

Centralized

Social Services and Welfare

No

Yes

Centralized

 


Citizen


Employees, Managers


Partners (Other Govt. Agencies, Industries)

Note: Govt. owned is shown as private areas are shown as .

 

 

2.

Service Model

 

Parameter

Present Mode of Operation

Future Mode of Operation

Service Availability

Not available at all

Available to 20% of the population

Service Quality

Non existing, intolerable

Mostly bad, occasionally good

Provider Service Management

Non Existing

Initial, Ad hoc

Business Strategy for the Service

Non Existing

Vision Mission defined

Legal, Technical and Human Infrastructure

Non Existing

Policies have been defined

Overall Management, Technical and Human Infrastructure of Small to Medium Businesses

Non Existing

Policies have been defined

 

3.

Suggested Solutions

 

Cost and Benefit Analysis:

 

Should be Done Whenever Possible

 

 

 

Policies

·         http://www.policiesandprocedures.com/

·         Guide to Writing Policy and Procedure Documents

·         Policies, Procedures and Internal Controls - a Standard Framework

·         www.oracle.com/partners/en/knowledge-zone/applications/042908.html

·         www.ucsc.edu/ppmanual/pdf/guide.pdf

·         www.volresource.org.uk/samples/checklst.htm

Centralized : Easy to implement uniform policies

 


Service Specific input

 

 

Tip: Large number of policies

 

Business Processes:

 

 

 

 

Application:

 

Strategy

Buy

 

Apps

None
 

 

For Centralized

It maximizes use of common resources.   
It makes standardization easier.  
It is easier to monitor and control.

 

Platform:

 

Computing Load

Low

 

Machine

MOSS 2007 [4GB RAM, 90GB Hard Disk] 
 HP c7000 Blade server 
 HP Modular SAN Array 1000

 

Middleware

Standard middleware (e.g., RPC, RDA, MOM)

Network:

 

Basic Network (Broadband network not required)

 

Security:

 

Basic security
 
 
For Decentralized: Harder to secure and recover

 

Architectural Consideration:

 

a portlet will be needed (a portal that can handle all business processes within this business functional area)

 

 

4.

Management Considerations

 

 

Business Continuity Planning Checklist
 

GOAL 1- Establish a good foundation
 

 

Action Plan Steps

Status

 

Identify a coordinator and/or team with defined roles

N/A

 

Conduct a business process and services inventory to understand which processes are mission-critical .

N/A

 

Determine acceptable levels of service during the recovery

N/A

 

Identify essential employees and other critical inputs (sub-contractors, services, logistics, etc.)

N/A

 

Conduct a technology asset inventory to determine and document the mission-critical technology components

N/A

 

Understand the rules or regulations governing your business operations.

N/A

 

Identify a budget: Quantify the potential costs of downtime or total business failure.

N/A


Knowledgeable individuals from Business Department
 

 

BCP Manager Name

 

 

BCP Manager Email

 

 

Alternate Manager Name

 

 

Alternate Manager Email

 

 

Senior management team

 

 

HR & legal team

 

 

Public relations team

 

 

IT team

 

 

GOAL 2—Develop a thorough plan
 

    Perform inventory on company’s hard and soft assets
 

 

Add Inventory Document Link (Hard Assets)

 

 

Add Inventory Document Link (Soft Assets Data etc)

 


    Backup Site Information
 

 

Address

 

 

Other Information

 

 

Others Business Functions , Process

 


    Structured walk-through
 

 

Date :

Feb-1-2011

 

Department / Business Unit

 

 

Members

 

 

Checklist Test Report

 

 

GOAL 3—Maintain the plan diligently
 

    Maintaining plan
 

 

Next Update Plan Date :

Feb-1-2011

 

Policies & Procedures

 


    BCP awareness training

 

 

Date :

Feb-1-2011

 

Objective

 

 

Department / Business Unit

 

 

Members

 


    Comparing BCP Test
 

 

(Last and Current test , missing item, enhancing features etc)

 

 

 

5.

General Integration Issues

 

This architecture document uses a service oriented architecture (SOA) based on components that provide these services. The components consist of the following (see the diagram)

  • BCs (Business Components) that imbed the business logic of the application and provide business services. At present, we are assuming one BC per application (you can modify it, if you wish)
  • FICs (Front-end Integration Components), also known as user integration components, that allow different types of user devices (e.g., mobile, handheld) to invoke the BCs.
  • BICs (Back-end Integration Components) that BCs to interact with different back-end and external applications.

Overall Integration Strategy Using SOA

SOA is especially suited for integration of diverse enterprise applications that include data warehouses and migration of applications. In particular, an SOA ESB (Enterprise Service Bus) provides a collection of technologies (middleware such as Web Services, adapters/gateways for protocol conversion, data transformers, transaction managers, and work/process flow systems) that allow diverse applications to talk to each other. For example, an ESB platform can allow new EB applications written for Web users to seamlessly communicate with back-end mainframe-based ERP systems, data warehouses and databases. At their best, ESB platforms hide all the complexity needed to enable interactions between applications that were developed at different times by using different middleware technologies. Thus ESB platform is not a new technology rather, it is a combination of well-known technologies that can integrate multiple applications. All applications (business components) provide services that are invoked through well defined interfaces

  1. Adapters are used for message and protocol translations. A Hub provides communications services between various service providers and consumers.
  2. An ESB may consist of one or more hubs.
  3. An ESB also provides Directory, Security & Administrative Services.

 

 

 

 

6.

Country/Region Specific Details

 

Special Recommendations Based on Country/Regional Factors

Business processes

  • Complying with administrative requirements (permits, regulations, reporting) issued by the government in this country is High .A "Compliance" business process is recommended (for example the mobile unit may have to get extra permissions and long delays to start operations)
  • Law Effectiveness is low in this country. "Physical security" is crucial (this is especially true for a mobile unit that may need to go to far off places).

Applications

  • English understandability is low. Special user interfaces (keyboards, user instructions, diagnostics) and documentation will be needed to address language barriers.

Technologies (platforms, networks)

  • English understandability is low. Special user interfaces (keyboards, user instructions, diagnostics) and documentation will be needed to address language barriers.
  • The Climate is mostly Dry. Wireless frequencies for WiMax in the microwave range (1 to 40 GHz) are highly effective

Security

  • Law Effectiveness is low in this country. Extra physical security is crucial (this is especially true for a mobile unit that may need to go to far off places).

Project Planning

  • Complying with administrative requirements (permits, regulations, reporting) issued by the government in this country is High .Extra time is needed for  "Compliance" (for example the mobile unit may have to get extra permissions and long delays to start operations)

Total Cost of Ownership

  • Venture capital availability is low then consider overseas funding institutes (e.g., World Bank)

Total Time to Install

  • The Population is large. The systems have to be very scalable.

 

 

 

 


B. Required Solution/System

 

Contents

  1. Introduction
  2. Basic characteristics of the system
  3. System type, way of functioning
  4. Way of system functioning: interoperable, high availability, ...
  5. Elements of the on-line system: central/distributed, e-forms or without,
  6. Safety
  7. Privacy
  8. Flexibility
  9. Capacity of the system: transaction per minute, response time, working regime, ...
  10. Software platform: list of acceptable platforms
  11. System implementation (conversion, migration, integration or so)
  12. Documentation
  13. Training
  14. Technical support
  15. Warranty
  16. Source code ownership

Others as needed

 

Application Requirements Document

 

 

Entrepreneurship

 

 

General Template

 

 


Table of Contents


Definitions and Terms

ACL

Authorized Control List

ACM

Association of Computing Machinery

AI

Artificial Intelligence

AIA

Application Integration Architecture

API

Application Programming Interface

ASP

Application Service Provider

ASP

Active Server Pages A Microsoft technology for building server side code

ATM

Asynchronous Transfer Mode a packet switching Technology used typically in high data rate networks

ATM

Automatic Teller Machine used in banking

B2B

Business to Business

B2C

Business to Consumer

B2E

Business to Employee

B2G

Business to Government

BREW

Binary Runtime Environment for Wireless

BSP

Business System Planning

CAD

Computer Aided Design

CAM

Computer Aided Manufacture

CBX

Computerized Branch Exchange

CCITT

Comit Consultatif Internationale de Tlgraphique et Tlphonique (The International Telegraph and Telephone Consultative Committee)

CDMA

Code Division Multiple Access

CDPD

Cellular Digital Packet Data

CGI

Common Gateway Interface - A Web gateway technology

CIO

Chief Information Officer

CORBA

Common Object Request Broker Architecture

COTS

Commercial Off-The-Shelf

CPU

Central Processing Unit

CRM

Customer Relationship Management

CSF

Critical Success Factors

CSMA/CD

Carrier Sense Multiple Access/Collision Detect

DBMS

Database Management System

DCOM

Distributed Component Object Model

DDBMS

Distributed Database Management System

DDL

Data Definition Language used in database management

DDTMS

Distributed Data and Transaction Management System

DML

Data Manipulation Language

DOD

Department of Defense

DSL

Digital Subscriber Loop

DTM

Distributed Transaction Manager

DTMS

Distributed Transaction Management System

EAI

Enterprise Application Integration

EB

Electronic Business

EC

Electronic Commerce

EDI

Electronic Data Interchange

EJB

Enterprise Java Beans

ERP

Enterprise Resource Planning

ETSI

European Telecommunication Standards Institute

FCC

Federal Communications Commission

FDDI

Fiber Distributed Data Interface

FDM

Frequency Division Multiplexing

FSO

Free Space Optics

FTP

File Transfer Protocol

GUI

Graphical User Interface

I/O

Input/Output

IDL

Interface Definition Language used in CORBA and other distributed object middleware services

IEEE

Institute for Electrical and Electronic Engineers

IMS

Information Management System - IBM DB/DC system on mainframes

IP

Internet Protocol

IPC

Interprocess Communication

IRM

Information Resource Management a management methodology

ISDN

Integrated Services Digital Network

ISO

International Organization for Standardization

ISP

Internet Service Provider

IT

Information Technology

ITU

International Telecommunications Union

ITU-T

International Telecommunications Union - Telecommunications Services Sector

J2EE

Java Version 2 Enterprise Edition

J2ME

Java Version 2 Mobile Edition

JDBC

Java Database Connectivity

LAN

Local Area Network

LDBMS

Local Database Management System

LLC

Logical Link Control

LMDS

Local Multipoint Distribution Service

LU

Logical Unit - an endpoint in the IBM SNA environment

MAC

Medium Access Control

MAN

Metropolitan Area Network

Mbps

Million bits per second

MMIT

Microsoft Mobile Internet Toolkit

MOM

Message Oriented Middleware

MVS

Multiple Virtual System - operating system on IBM's mainframes

NBS

National Bureau of Standards

NFS

Network File Services - SUN Microsystem's File System for Networks

NIST

National Institute of Standards and Technology

OAG

Open Application Group a standards organization

ODBC

Open Database Connectivity a de-facto standard for remote SQL

OMA

Open Mobility Alliance

OMG

Object Management Group the group that developed CORBA

OODBMS

Object-Oriented Database Management System

OOPL

Object-Oriented Programming Language

OS

Operating System

OSF

Open Software Foundation

OSF-DCE

OSF Distributed Computing Environment

OSF-DME

OSF Distributed Management Environment

OSI

Open System Interconnection

PBX

Private Branch Exchange

PGP

Pretty Good Privacy

PKI

Public Key Infrastructure

QoS

Quality of Service

QPSK

Quadrature Phase Shift Keying

RDA

Remote Database Access

RFID

Radio Frequency Identification

RPC

Remote Procedure Call

SCM

Supply Chain Management

SET

Secure Electronic Transaction a security standard

SNMP

Simple Network Management Protocol - TCP/IP Network management Protocol

SOAP

Simple Object Access Protocol part of Web Services

SONET

Synchronous Optical Network

SQL

Structured Query Language

SSL

Secure Socket Layer

TCP

Transmission Control Protocol

TCP/IP

Transmission Control Protocol/Internet Protocol

UDDI

Universal Description, Discovery and Integration - a registry for Web Services

UDP

User Datagram Protocol - a protocol that runs on IP

UMTS

Universal Mobile Telecommunication System (Mainly 3G Cellular Technology)

UWB

Ultra Wideband

VAN

Value-added Network

VPN

Virtual Private Network

VXML

Voice eXtensible Markup Language

WAN

Wide Area Network

WAP

Wireless Application Protocol

WLL

Wireless Local Loop

WML

Wireless Markup Language

WS

Web Services

WSN

Wireless Sensor Network


1. Overview and Business Drivers

Web Publishing

Publishing content on the web is one of the oldest application of web. You basically store your files (HTML/XML) on a web server so that the customers can access this content through Web browsers. The growing number of Web sites that publish content (known as "resources") to be accessed transparently by Web users is the main strength of WWW. Examples of the Web sites at present are corporate Web sites, university Web sites, publishing/advertising Web sites, travel agency Web sites, and small business Web sites. Web sites can be large (e.g., large corporations may dedicate several machines as Web sites) or small (smaller companies may rent or lease portions of a Web site).

Business Needs (edit and modify to fit your needs)

  • need to improve sales
  • need to improve customer satisfaction
  • need to provide new services
  • need to re-engineer business processes for efficiency
  • need to standardize operational processes.
  • need to gain economy in services, support, and buying power.
  • need for better reporting. And tracking
  • need to enable integration / automation with internal systems .
  • need to enable integration / automation with external providers (B2B) .
  • need to improve workflow mechanism to capture and manage business processes.
  • need to eliminate individually programmed software that provides little or no compatibility between markets, regions, and headquarters.
  • need for a support system that provides auditing, tracking, interfacing, and automation of tasks and workflows.
  • need to reduce duplicity in data, processes, and effort.
  • need to improve forecasting and budget tracking in all facets of the business.
  • need to quickly design and implement processes and technology changes across the organization.
  • need to monitor depreciation of assets.

2. Background Information

Web Publishing
Additional Information

Although conceptually a Web site is a catalog of information for each content provider over the Web, in reality, a Web site consists of three types of components: :

  • Content files such as the HTML documents
  • A Web server (a program) that receives browser calls and accesses contents, and/or
  • Gateways that can generate Web content (e.g., generate HTML pages) and provide access to non-Web content (e.g., relational databases).

Setting up a Web site involves a large number of issues such as the following:

  • Deciding who will develop the Web site, i.e., your own organization or an outside service provider.
  • Determining rent versus own issue, i.e., will the site be owned by your organization or will you rent/lease space on an existing Web site (this is called "virtual hosting").
  • Choosing a Web site platform, i.e., will the Web server and contents reside on a UNIX or Windows NT platform.
  • Choosing a sharing level, i.e., will a machine be dedicated as a Web site or the Web site software will coexist with other software (e.g., LAN software).
  • Providing and controlling access to the site, i.e, determine the networking configurations and the security firewalls to be set up.
  • Designing the site, i.e., designing home pages, assigning defaults, and server configurations.
  • Management and support considerations such as backup/recovery, site security, site administration, hotline support, etc.


Many Web servers for different classes of Web users are state of the market. Apache, Sun Server, and Netscape servers are examples. The choice of a server depends on factors such as ease of installation, performance, security, manageability, and user friendliness.

Web publishing represents the C2B - information services business pattern.

Business Pattern  

In this pattern, the enterprises are mainly information providers. No purchasing takes place (that is a different business pattern).

This is one of the oldest model of Web and is largely used for advertisements and information dissemination through Web sites. Users, who can be either internal or external to the enterprise, interact with enterprise transactions and data. In some cases, there may be a need to access back-end applications and data. This pattern is relevant to those enterprises dealing with goods and services not normally listed in and sold from a catalog. It encompasses all user-to-business interactions not covered by the User-to-Online Purchase pattern. Many (but not all) of the functions supported by the User to Business pattern relate to Customer Relationship Management (CRM) systems.

Examples:

Government

  • Submit tax returns
  • Renew automobile licenses
  • Download forms/applications
  • Submit forms/applications

Manufacturing

  • Review required parts/services
  • Locate service centers
  • Register for training classes
    Submit/track orders

Insurance Industry

  • Locate a nearby office
  • Locate brokers or agents
  • Financial planner and insurance needs analysis tool
  • Portfolio summary
  • Policy summary and details
  • Claims submission and tracking
  • Online billing

Discount Brokerage

  • Portfolio summary
  • Detailed holdings
  • Buy and sell stocks
  • Transaction history
  • Quotes and news

Convenience Banking

  • View account balances
  • View recent transactions
  • Pay bills/transfer funds
  • Stop payments
  • Manage bank card

3. Application Functional Requirements

Main Functional Requirements

  • Support static content in HTML and XML  documents
  • Support dynamic content through gateways that can dynamically generate Web content from non-Web resources (e.g., relational databases).
  • Intuitive and natural design.
  • Support a Web standard Web server (MS IIS or Apache)
  • Support Linux or Windows platform.
  • Provide appropriate sharing level (dedicated versus shared machine)   
  • Support backup/recovery, site security, site administration, hotline, etc.

4. Information Models (Use Cases, Class Diagrams, Sequence Diagrams)

== Insert information models here   

5. Logical Architecture (Application Pattern)

EntrepreneurshipLogical Application Architecture

This logical architecture consists of the following (see the diagram)

  • Business Layer that provides the business services such as the following:
  • Backend resources
  • External (Partner/Supplier) Resources
    • These may be government and/or regulatory agencies.
  • The Front-end Integration Layer that allows different types of user devices (e.g., handhelds, voice over IP) to invoke the Business Layer. This layer:
    • Integrates the diverse user device technologies
    • Provides necessary security services    
  • Back-end Integration Layer that interacts with different back-end and external applications. This layer:
    • Integrates the diverse back-end databases and applications
    • Provides necessary security services

6. Architecture and Integration Requirements (General)

Distributed Architecture Requirements   

== Modify the following as needed    

  • The application must be decomposed into well defined business components that can be deployed, installed, and invoked independently over the Internet.
  • The application must support an N tiered (N > 2) architecture with client, server, and databases.
  • The architecture must support a front-end as well as back-end integration tiers.  
  • The application must support a replication mechanism so that all data and processes do not reside on one location.  
  • All levels of the architecture must be both forward and backward compatible.
  • The application must be highly configurable within the server environment allowing for multiple workflow options concurrently.
  • The application must allow for internal application customization in a GUI environment.

Interface/Integration Requirements

== Modify the following as needed    

  • The application must support well defined interfaces for external integration.
  • The application programming interface must be documented and supported.
  • The application must provide loose coupling with external systems for flexibility
  • The application must have a browser-based GUI for user interactions 
  • The application must have conversion capabilities for different financial and regional data items (e.g., dollars to Euro).
  • The application must be able to download external data files .
  • The application must be able to process transactions with third party systems.
  • The application must be able to interchange status information with third party systems for logistics functions.
  • The application should be capable of supporting data mining applications.
  • The application must provide an effective and efficient interface for highly mobile personnel.

7. Architecture and Integration Requirements

Front-end Considerations

  • Simple Web browser interface over HTTP because of lightweight informational interaction

Back-end Considerations

  • No interfaces with back-end systems
  • No data translation needed for back-end applications

B2B Considerations

  • No interfaces with external systems for B2B interactions
  • No data translation needed for B2B applications

Special Considerations

  • Scalability of this service should be a (major) concern due to the population of intended users.

8.  Operational Requirements (Generic)    

Security/Permission Requirements  

  • The solution shall allow for the creation of privileges and permissions based on work groups composed of different users at different sites.
  • The solution shall enforce privileges and permissions on data fields and user screens.
  • The application will support privileges for read, delete, and edit.
  • A local administrator will be able to assign all user privileges and permissions.  
  • The application must conform to security standards, policies, and procedures established by the company

Performance Requirements

  • The system must provide adequate turnaround for interactive work. 
  • The system should be robust to handle user access needs without crashes and restarts
  • The system must allow backup of needed data while being continually available to users for business as usual operations.
  • The system should degrade performance gracefully if workload increases dramatically.

Hardware Requirements

  • The application server must support the following platforms:  Windows/Linux/Others (specify)   
  • The application server must support the following platforms:  Windows/Linux/Others (specify)   
  • The application client must support the following platforms:  Windows/Linux/Others (specify)   
  • The application must support a hardware High Availability environment through replicated servers.
  • Add more  

Software Requirements

  • The application server must utilize the most recent operating systems from the following list: Windows/Linux/Others (specify)  
  • The application client must utilize the most recent browser version from the following list: Internet Explorer/Netscape/FireFox (specify)   
  • The application must utilize relational databases.
  • The application must utilize a commonly available and used  development environment such as Rational Rose.
  • Add more

9. Vendor  Support Requirements

Application Service Provider (ASP) Support

  • The ASP must guarantee, in writing, complete privacy and security of application and data.
  • The ASP must support the application 24 hours a day, 7 days a week, 365 days a year.
  • Response of an application failure must be made according to the failure types by the ASP.  The application shall use 3 failure types: critical, important, and minor.
    • Critical failure shall mean that the System is un-useable. The response to a critical shall be immediate to 3 minutes with 30 minutes to repair after vendor notification.
    • An Important failure shall mean that some part of the system is un-useable. The response to an important failure shall be 1 hr with 4 hrs to repair after vendor notification.
    • A Minor failure shall mean that impairment is affecting application performance. The response to a minor failure shall be within 24 hours with 7 days to repair after vendor notification.
  • The ASP will support necessary upgrades of the software features.
  • The ASP must provide all the necessary documentation needed for the customer to use the applications (e.g., a user guide, troubleshooting information, etc).  

Back Up and Maintenance Support

  • The backup files shall be generated and stored according to the following IT standards
    • backups will be taken once a day (recommended) or once a week (required)
    • backup copies will be stored at an external site for safety    
  • The application shall support an incremental online backup of the complete system, including database, as well as a full weekly online backup..
  • The application vendor must provide maintenance and upgrades on a regular basis. 

Documentation Support

The application provider, in the following discussion, may be an outsourced development house or an internal software development group.

  • The application vendor must provide a Users guide for all user categories interfaces.
  • The application vendor must provide an Administrators guide for the application.
  • The application vendor must provide online Help on all client interfaces.
  • The application vendor must supply documentation on the applications maintenance.
  • The application vendor must provide documentation on each database used in the proposed solution.
  • The application vendor must supply upgrade instructions and release notes  30 days before a release.
  • The application vendor must provide upgrade and rollback procedures for new releases.

Training Support

  • The application vendor must provide on-site and/or application vendors site training. .
  • The application vendor must provide interactive training on CD-ROM or through Web.   

10. SOA Considerations

  • Eliminate redundancy among services.
  • Services should be reused instead of created whenever possible
  • Services must be compliant with the existing reference architecture
  • Services should have a different response time based on the access method
  • Give priority to services with highest value and highest potential for reuse. 
  • Decide which  services to do? And, which services to do first?
  • Determine how will SOA development, execution, and maintenance of shared services be funded
  • Determine who owns the service
  • Ensure that SOA projects remain aligned with business goals and deliver the expected business results 

Main Suggestion:

  • Create a process for proposing services, for example:
    • Proposals are submitted to a team room
    • Require documentation/justification
    • Reviewed weekly by a committee established by the SOA Center of Excellence to respond:
      • Accepted.
      • Already exists, use that one
      • A similar service is planned by another group.  Coordinate with them.
      • Inappropriate (low value, low potential for reuse)
      • Use external / outsourced service

Suggestion

For Interoperability: A common approach used in interoperability is an ontology mapping table (OMT). Simply stated, ontology represents a vocabulary. An OMT translates the terms in one system to the other and thus provides the bridge between disparate systems (see a simple example below).

Term in System1

Term in System2

Customer

Buyer

Laptop

Computer

Item

Product

Many organizations are pushing the use of the Semantic Web (with XML) for interoperability with focus on eGovernment, eHealth or eBusiness. Examples are:

 

 

 


C. Detailed Requirements

 

 

Contents

 

  • 1. Software specification
    • 1.1. Modules: list, description
    • 1.2. Functionalities: detailed explained
    • 1.3.
  • 2. Hardware specification
    • 2.1. Servers: DataBase, Application, Back-Up,
    • 2.2. Storage
    • 2.3. Network: routers, switches, Firewall and Network security devices,
    • 2.4. Back-up system
    • 2.5. UPS
    • 2.6.
  • 3. Licenses (requirements, limitations, ...)
    • 3.1. DB
    • 3.2. OS
    • 3.3. Other components

Other as needed

 

 

Computer Aided Strategic Planner Tools, Techniques and Standards Used

Planning Phases

Activities Performed

Tools, Techniques & Standards Used

P0 (Government Modeler) Choose a Country and create a Government Pattern

S1: Define the country Profile and specify the level of use for the ICT  

Fetch and use various indicators from sources such as World Economic Forum, UNPAN, ITU 

S2: Create a government pattern for the chosen country

Use the Patterns Repository to fetch and display a generic government pattern

S3: Customize the pattern based on user inputs

Defaults for the patterns are based on external data sources

P1 (Initializer): Choose an Area (Domain) and  Do Information Gathering 

S1; Define a service in different areas that support the MDGs (e.g., healthcare, education, economic development)

The services are based on the government pattern and use the ITIL ITIL (IT Infrastructure Library: http://www.itil-officialsite.com/

S2: Get general information, educational resources and best practices

Extensive literature from diverse sources is accessed and displayed.

S3: Do a self assessment of the PMO (present method of operation) and FMO (Future Method of Operaation)

Uses the Capability Maturity Model (CMM) measures (0 to 5) for assessment.

P2 (Strategic Planning): High Level Planning (Management Focus)

Cost-benefits tradeoffs

Uses the McFarland Model

Strategic analysis (buy, rent, outsource)

Uses an intuitive decision model based on time, in-house expertise,

Policies and procedures needed for the service

Policies from different sources are fetched and displayed. Oracle Policy Automation

 Business processes needed

TOGAF (The Open Architecture Framework) and US-FEA (Federal Enterprise Architecture)

Technologies (apps, platforms, networks)

OAG (Open Application Group -Website: http://www.oag.org/, W3C (http://www.w3c,org/), ISODP (ISO Distributed Processing), Cisco guidelines

Security & business continuity planning

SSI (System Security Institute), and ISO 9000 (for quality mgmt)

Project Management & Governance

PMBOK (Project Management Book of Knowledge) by Proj Mgmt In.(PMI)COBIT (Control Objectives for Information

Interoperability and Integration Considerations

SOA, SPOCS (large European initiative for interoperability https://mobile.harrisburgu.edu/exchweb/bin/redir.asp?URL=http://www.eu-spocs.eu/)

P3 (Detailed Planner): (Technology Focus) -- Through Simulations

Consolidated Report that shows:

  1. Summary of the interactions
  2. Requirements (RFP) format
  3. Standards used (with explanations)

Requirements document is based on International Institute of Business Analysis): Website: http://www.theiiba.org/

Detailed Planning & Implementation Tools

Games, simulations, planning tools,

P4: Monitoring and Control (Quality Focus)

Detailed project management for monitoring and controls with quality focus

PMBOK (Project Management Book of Knowledge) by Project Mgmt In.(PMI), COBIT (Control Objectives for Information), ValIT and RiskIT.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


D. Project Management Requirements

 

Contents

 

  1. Implementation plan (phases, steps, ...)
  2. Communication plan
  3. Schedule plan
  4. Reporting plan
  5. HR plan (from the company)
  6. Change request plan
  7. Development / environment / platform plan
  8. IT of the
  9. Control / monitoring plan
  10. Testing and acceptance plan (audit or so, if at all)
  11. Support plan

 

Others

 

1.Project Management Overview

 

 

Project Management Highlights at a Glance

PMBOK Approach: Project Management Institute (http://www.pmi.org/) has developed A Guide to the Project Management Body of Knowledge (PMBOK Guide) that is accepted as providing best practice processes in project management.  The PMBOK identifies 42 processes which are organized into five process groups (Initiating, Planning, Executing, Monitoring and Controlling, and Closing) which may roughly correspond to time periods within a project and into nine knowledge areas (Scope, Time, Cost, Quality, Human Resources, Communication, Risk, Procurement, and Integration) within the process groups. The discussion in this section is based on PMIBOK.  

 

Lean Project Management: An alternate approach  that deviates somewhat from the PMBOK approach is Lean Project Management which is based on lean manufacturing.  A white paper on this approach can be found at http://www.qualiscope.ca/LPMRules_CEmond.pdf

 

Evaluating Project Success: Generally accepted project success criteria include:

  • Project is on time and within budget 
  • Product meets stakeholder expectations
  • Product conforms to requirements and specifications
  • Product performs and can be used as intended

 

Handling Large Scale Projects:

  • Treat it as Project of Projects (POP)  Problem
  • Use concepts from managing systems of systems
  • Decompose the major project into subprojects
  • Treat each subproject as a WBS activity
  • For each subproject, as a project manager (PM)
  • Develop  PERT/CPM/Gant charts for the major overall project only to identify critical paths and bottlenecks (let the PMs create their own project WBS and PERT/CPM/Gant charts)    

 

 

2. Checklist for Project Management

Project management is primarily concerned with determination and documentation of project activities, roles and responsibilities.  The following form provides a good project management checklist. In addition to the report produced by PISA, it is a good idea to fill out this form to capture overall project management information and customize it (of course!).

 

Project Name:

Prepared By:

 

Date Prepared:

 

Revision Number:

 

Project Objective

 

Background

Brief describe how and why this project came about

Project Scope

What business and technical functions are in and out of scope?

What sites (locations) locations are in and out of scope?

What type of IT work does it involve circle as many as apply (application, platform, network, security, system integration)

What are the project interfaces with other projects?

What business procedures are required?

What production operations procedures are required?

Will an Acceptance Test Plan and testing be required?

What training is required?

What documentation is required?

What are the critical requirements?

Constraints

Cost constraints

Time constraints (project completion date)

Technical constraints (existing hardware/software constraints)

Management and organizational constraints (e.g., policies, procedures)

 

Business Case

 

Project Justification

Why do this project?

What happens if we don't do it?

Why do it now?

How critical will be the impact of this project?

Risks

What could go wrong? (both systems-related and user-related)

Countermeasures

How will you avoid this?

Costs

List all hardware, software, network, staff, facilities and other costs

 

Organization

 

Project Sponsor

Who will signoff the requirements?

Who will remove obstacles?

Who will accept the finished product?

Project Lead

Who will execute the project initiation (e.g., Project Manager or Business Analyst)

Resources & Responsibilities

What additional resources will be required?

What are they expected to do?

 

Schedule

 

Start Date

When will the project start?

End Date

When will it end?

Estimate

How many effort hours?

How many elapsed hours?

What assumptions are you making?

Final Product

What is the end product?

Project Approach

What are the milestones?

Interim Products

What are the products of the milestones?

 

Project Initiation Approvals

Requested Date:

 

Client Requester:

 

Date:

 

Project Manager:

 

Date:

 

Department Manager:

 

Date:

 

 

 

3. Detailed Project Management for Monitoring and Control

The Report contains Project management information on different project phases like:

  1. Initiating
  2. Planning
  3. Executing
  4. Monitoring
  5. Closing

Monitoring and Control

Summary Report

Step 1 :Initiating

Business Case

 

Project Name:

 

 

Date

Jan-17-2011

 

Prepared By

 

 

Background

 

 

Objectives

 

 

Current Situation and Problem

 

 

Critical Assumption

List and describe all the assumptions associated with the ability to address the key requirements—and the potential impact of those assumptions if they are not addressed.

 

Recommendation

 

 

Preliminary Project Requirement

 

 

Budget Estimates

 

 

Schedule Estimates

 

 

Potential Risk

Identify the major risks that will need to managed or mitigated in the execution of this project.

 

Business Charter

 

Organization Name

 

 

Project Title :

 

 

Start Date :

Jan-15-2011

 

Finished Date :

Jan-15-2011

 

Project Manager :

 

 

Contact Number :

 

 

Email

 

 

Project Goals & Objectives

Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case.

 

Approach

Approcah

 

Name

Role

Responsibilities

 

Sponsor

Approve or deny scope change requests as appropriate Evaluate need for scope change requests Accept project deliverables

 

Project Manager

Measure and verify project scope Facilitate scope change requests Facilitate impact assessments of scope change requests Organize and facilitate scheduled change control meetings Communicate outcomes of scope change requests Update project documents upon approval of all scope changes

 

Team Lead

Measure and verify project scope Validate scope change requests Participate in impact assessments of scope change requests Communicate outcomes of scope change requests to team Facilitate team level change review process

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Step 2 :Planning

Project Scope Statement

 

Project title:

 

 

Justifications

e.g market demand ,business need ,customer request ,tchnological advance ,legal requirement etc)

 

Requirment

 

 

Assumption

Assumptions form the basis for project planning (e.g., support and attention will be provided by the Sponsor; Resources will be available to adequately staff the project, etc.). Assumptions are a source of project risk and must be identified.

 

Project Management Deliverable

Team Contract, Business Case ,Project Charter,Project Budget, Quality Assessment Guidelines,Project Risk Assessment,Status Reports,Any other documents required to manage the project

 

Product Deliverable

 

 

Project Team Communication Plan

 

Type

Reports

 

Deliverable

 

 

Description

,

 

Delivery Method

email

 

Frequency

Daily

 

Owner

 

 

Audience

 

 

Type

Reports

 

Deliverable

 

 

Description

 

 

Delivery Method

email

 

Frequency

Daily

 

Owner

 

 

Audience

 

 

Type

Reports

 

Deliverable

 

 

Description

 

 

Delivery Method

email

 

Frequency

Daily

 

Owner

 

 

Audience

 

 

Type

Reports

 

Deliverable

 

 

Description

 

 

Delivery Method

email

 

Frequency

Daily

 

Owner

 

 

Audience

 

 

Type

Reports

 

Deliverable

Deliverable

 

Description

 

 

Delivery Method

email

 

Frequency

Daily

 

Owner

 

 

Audience

 

 

Procurement Management Plan

Item/Service

Justification

Needed By(date)

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

 

 

Jan-15-2011

Project Statement of Work

Project Name:

 

 

Date

Jan-15-2011

Prepared By

 

Scope of Work

describes the work to be done in detail and specifies the hardware and software involved and the exact nature of the work to be done

Location of Work

describes where the work is to be performed. This also specifies the location of hardware and software and where people will meet to perform the work.

Period Of Peerformance

specifies the allowable time for projects, such as start and finish time, number of hours that can be billed per week or month, where work is to be performed and anything else that relates to scheduling.

Deliverables Schedule

 

Applicable Standards

 

Acceptance Criteria

specifies how the buyer or receiver of goods will determine if the product or service is acceptable, what criteria will be used to state the work is acceptable

Specail Requirement

specifies any special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in the contract specifics.

 

Step 3 :Executing

Change Request Form

 

Project title:

 

 

Justifications

Jan-15-2011

 

Requirment

 

 

Assumption

 

 

Project Management Deliverable

 

 

 

Step 4 :Monitoring & Control

Project Status/Progress Report

 

Project Title :

 

 

Date

Jan-15-2011

 

Reporting Period

From Jan-15-2011
To    Jan-15-2011

 

Team Member

 

 

Dapartment

 

 

Work Completed

 

 

Work next reporting period

 

 

Problems

 

 

Suggestions /Issues

 

 

Project Changes

 

 

 

Step 5 :Closing

Client Acceptance

Project title:

 

Project Manager

 

Name

Title

Date

 

 

15-Jan-2011

 

 

15-Jan-2011

 

 

15-Jan-2011

 

 

15-Jan-2011

Project Lesson Learned

Project title:

 

Date

Jan-15-2011

Prepared By

Project Manager

Approved By

Project Sponsor

Project Success

Factors That Supported Success

Senior Management Committment

The committment of the organization’s senior management, everyone involved in the project will have a sharper focus.

Adequate Project Funding

Devote time and attention at the project’s beginning to analyze and apply realistic costs to the components.Set the realistic figures

A Comprehensive Project Plan

Correlate the length of time allocated to project planning

Other Notable Project Successes

Factors That Supported Success

 

 

 

 

 

 

Project Shortcoming

Recommended Solutions

Unclear roles and responsibilities

Make sure that all key stakeholders understand their roles and responsibiliites in project

Organizational behavior

Improve user communications up front from Senior Management regarding expected behavior.

 

 


your selected project planning model : tp-rapid Traditional Rapid

Traditional Rapid Linear Project Management

  • Project goal(s) are very clear at inception.
  • Requirement can be "almost " completely established at project inception ... before planning begins - Project Manager and client convinced of completenness..
  • Usual sequence/pattern of activity expacted.
  • Five process groups are executed once.
  • Minimum changes to scope expacted. Scope change request distrupt the plan.
  • Team members need not to be co-located.
  • Time and funding constraints.
  • Routine / reptitive tasks
  • Tools and templates are available ir easily obtainable
  • Designed t compress the project schedule to deliver the solutioin faster.
  • Planning is still done once.
  • Dependencies within each set should be high but between each set should be low.
  • Increase risk due to increased possibility for resource conflicts and reduced time to analyze and resolve problems.
  • Increased overhead & time to manage inter & intra feature set issues.

Risk

  • Does not accommodate change well
    • Almost any change request will cause problems with the schedule
  • Cost overruns
    • Client sees no work until late in the project.If problems with testing / acceptance, more work will have to be done…but most of the budget will have been spent
  • Too long before any deliverables are produced
    • Client sees product late in the project.  This leaves very little time for change (if funds are available for the work).  The project deadline is near and team members may already be allocated to other projects.
  • Requires complete and detailed plans.
    • A complete plan may be a waste of time.  Every (approved) change request leads to a revision to the project plan.  Danger of plans turning into non-value added work
  • More focused on process than providing business value
  • Focus is completing the project on time, within budget and according to requirements.  Client’s requirements may not actually satisfy the business need.  i.e. the deliverable does not do what the client expected.
  • Work of the project is compressed into shorter time frame. There is less time to investigate and implement corrective actions for items such as:
    • Scope change
    • Resource contention
    • Problem resolution

 


Your Selected Checklist

Quality Monitoring and Control Checklists

 

A) Checklist for Quality Planning

Getting Started in Quality Planning

  • Pick the right project (not too large, not too small or insignificant) for quality improvement
  • Develop a quality management plan.
  • Define a quality policy. Establish quality goals and timeline when the goals can be achieved. Be as specific as possible. Examples:
    • Reduce defects by 30%
    • Reduce customer complaints by 30%
    • Cut down cycle time by 50%
    • Good example of a balanced policy: “We will build good ships here, at a profit if we can, at a loss if we must, but always good ships”. (From a naval shipyard in UK in late 1800s)
  • Determine who is in charge and who is responsible for quality.

Identify Customers

•           Identify all relevant customers by analyzing contracts (external customer who is paying for it), project organization (internal customers who are stake holders), and the intended product use (the end-user who will be using the product).  
•           Prioritize customers. Not all customers are equally important. Compare customers against each other to develop better understanding. For example, customer A may be more important than customer B, less important than customer C or equal to customer D. You could rank customers in terms on a scale of 0 to 10 (10 being crucial).

Establish Requirements

Identify requirements of all relevant customers.
Prioritize requirements from each customer’s point of view.
Prepare customer-weighted prioritization.
Define explicit, measurable specifications for each requirement. For example, how will you know if a specific requirement has been satisfied?

  

B) IT Specific Quality Checklist  

Break the Projects into Phases/Stages (Macro Analysis)

  • For Software Development Projects: Breakdown the overall development process into phases (e.g., life cycle phases such as requirements, design, etc.). A typical software life cycle is shown above.
  • For IT Service Projects: Breakdown the service into stages (e.g., initiation stage, problem definition stage, solution development stage, solution delivery stage, post-delivery stage, etc)
  • Make sure that the work between the stages flows smoothly without any delays and wastage of resources. For example, the transition between design and development/implementation should wait for 2 months for a programmer to be assigned. 
  • Make sure that the results produced by each stage/phase are of high quality (e.g. no defects, no reworks, etc.). This means that the results produced by ALL phases/stages are of high quality and not just the final code that is delivered to the user.  
  • Use project management tools and diagramming techniques such as PERT/CPM and others to properly manage the project.
  • Make sure that each stage/phase considers processes, technologies and people issues. 

Develop Detailed Work Steps from the Phases/Stages of work (Micro Analysis) 

This activity refines the phases/stages identified previously by using the following steps: 
Breakdown each stage/phase into very detailed “work-steps” (5 or more steps per phase). Work steps usually include a list of supplies (e.g., technologies) for a particular job, plus detailed guidance on how to do the work (e.g., best practices in software development).
Make sure that the work steps and instructions include mundane, day-to-day jobs that must be done correctly, in a certain order, and without mistakes. ensure that the work steps conform to the company policies and procedures. Use your written work steps to train software developers, supervisors and managers. Use the work steps also for testing and for internal audits.
The main idea is to use your work steps for breaking down jobs and making improvements.   In short, use your work instructions to make sure the work that must be done, gets done right.

Refine Macro/Micro Analysis based on Frameworks

Refine the work steps (the process) by using Lean approach (i.e., no waste no-where) . Thus Lean can be used for process improvement.
Define the results produced (no defects, no rework, do it once and do it right) by using the Six Sigma approach. Thus Sigma can be used for end-product/service improvement. 
Use the CMMI approach to start at the right level and then go to higher levels gradually. It is a good idea to start with CMMI Level 2 and then go higher. Basically, CMMI levels can be used for “continuous improvement”. 
Make sure that a right balance of processes, people and technologies exists throughout (too much technology and no attention to processes and people is not good).
Familiarize yourself with the available frameworks. Exhibit 1 shows some key resources to get started.         

 

Selected References on Quality Frameworks

CMMI Main Website (www.sei.cmu.edu/cmmi/

  • Six Sigma and Lean Tutorials: The overview and references on Wikepedia on these topcs are pretty good.
  • ISO 9000 Quality Management Program weblink (http://www.iso.org/iso/qmp)  is a pretty good starting point for ISO 9000 info.
  • ITIL official website (http://www.itil-officialsite.com/home/home.asp)

Note: After reviewing these websites briefly and getting an idea, you should do a Google search for more specific articles by, for example, looking for “LSS versus CMMI”. Articles comparing the key frameworks are always appearing in the literature.


C) Quality Assurance Checklist 

Identify QA Activities

  • Define activities that will ensure project performance conforms to requirements. These activities are the main responsibilities of the QA group. The activities may be actually performed as part of the Work Project activities (e.g., project/service phases/stages, work steps, etc.) but are still the responsibility of the QA group.  
  • Develop metrics for each activity, i.e. number of defects, number of calls handled in an hour, etc.  

Assemble a QA Plan

  • Assemble quality assurance activities into a quality assurance plan.
  • Include what, when, and who.
  • Include processes, technologies and people in the activities

Example of a QA activity: 

  • Requirement: “answer 99% of hotline calls within one ring”
  • Assurance activity: Determine percentage of calls answered on one ring during a 48 hour period
  • Metric: percentage of calls answered in one ring

Sample quality assurance plan:

A QA plan documents all QA activities so that they can be managed and improved continuously.  The following table could be used for a QA plan.

Activity no

Requirement

Specific

Assurance Activity

Schedule

Responsible Entity

A172

Calls answered promptly

99% within one ring 

Calls answered per 48 hours

Done several times a week

Joe Mason

D)  Quality Controls Checklist  

  • Monitor and measure project performance.
  • Compare results to specifications.
  • Take action based on results.
  • Adopt a continuous quality improvement model, i.e., institutionalize the lessons learned and use them over and over again.  

The following (plan, do, check and act) circle represents continuous quality improvement.

q-circle