RFP Guide


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. . .




( Entrepreneurship )


( Uruguay )







A. Business process description



  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


  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.




Government Model


Reliance on Web

No use of Web(Paper-based systems)

Mobility Reliance

No use of mobile computing

E-Readiness Index


Networked Readiness Index (WEF)


Desired use in Services

Few Services

Time Horizon

One year

Population (2008) millions


GDP (Billion USD) (2008)


Landline Phone Connections per 100 citizens


Cellular Subscriptions per 100 citizens


Internet Users per 100 citizens


Broadband Users per 100 citizens



Industry Pattern

Owned by Government

Regulated by Government

Mode of Operation





e-Government Services




Law Enforcement and Public Safety
























Social Services and Welfare






Employees, Managers

Partners (Other Govt. Agencies, Industries)

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




Service Model



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



Suggested Solutions


Cost and Benefit Analysis:


Should be Done Whenever Possible





·         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:













For Centralized

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




Computing Load




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



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



Basic Network (Broadband network not required)




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)




Management Considerations



Business Continuity Planning Checklist

GOAL 1- Establish a good foundation


Action Plan Steps



Identify a coordinator and/or team with defined roles



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



Determine acceptable levels of service during the recovery



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



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



Understand the rules or regulations governing your business operations.



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


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





Other Information



Others Business Functions , Process


    Structured walk-through


Date :



Department / Business Unit






Checklist Test Report



GOAL 3—Maintain the plan diligently

    Maintaining plan


Next Update Plan Date :



Policies & Procedures


    BCP awareness training



Date :






Department / Business Unit





    Comparing BCP Test


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





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.






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).


  • 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


  • 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



  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






General Template



Table of Contents

Definitions and Terms


Authorized Control List


Association of Computing Machinery


Artificial Intelligence


Application Integration Architecture


Application Programming Interface


Application Service Provider


Active Server Pages A Microsoft technology for building server side code


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


Automatic Teller Machine used in banking


Business to Business


Business to Consumer


Business to Employee


Business to Government


Binary Runtime Environment for Wireless


Business System Planning


Computer Aided Design


Computer Aided Manufacture


Computerized Branch Exchange


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


Code Division Multiple Access


Cellular Digital Packet Data


Common Gateway Interface - A Web gateway technology


Chief Information Officer


Common Object Request Broker Architecture


Commercial Off-The-Shelf


Central Processing Unit


Customer Relationship Management


Critical Success Factors


Carrier Sense Multiple Access/Collision Detect


Database Management System


Distributed Component Object Model


Distributed Database Management System


Data Definition Language used in database management


Distributed Data and Transaction Management System


Data Manipulation Language


Department of Defense


Digital Subscriber Loop


Distributed Transaction Manager


Distributed Transaction Management System


Enterprise Application Integration


Electronic Business


Electronic Commerce


Electronic Data Interchange


Enterprise Java Beans


Enterprise Resource Planning


European Telecommunication Standards Institute


Federal Communications Commission


Fiber Distributed Data Interface


Frequency Division Multiplexing


Free Space Optics


File Transfer Protocol


Graphical User Interface




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


Institute for Electrical and Electronic Engineers


Information Management System - IBM DB/DC system on mainframes


Internet Protocol


Interprocess Communication


Information Resource Management a management methodology


Integrated Services Digital Network


International Organization for Standardization


Internet Service Provider


Information Technology


International Telecommunications Union


International Telecommunications Union - Telecommunications Services Sector


Java Version 2 Enterprise Edition


Java Version 2 Mobile Edition


Java Database Connectivity


Local Area Network


Local Database Management System


Logical Link Control


Local Multipoint Distribution Service


Logical Unit - an endpoint in the IBM SNA environment


Medium Access Control


Metropolitan Area Network


Million bits per second


Microsoft Mobile Internet Toolkit


Message Oriented Middleware


Multiple Virtual System - operating system on IBM's mainframes


National Bureau of Standards


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


National Institute of Standards and Technology


Open Application Group a standards organization


Open Database Connectivity a de-facto standard for remote SQL


Open Mobility Alliance


Object Management Group the group that developed CORBA


Object-Oriented Database Management System


Object-Oriented Programming Language


Operating System


Open Software Foundation


OSF Distributed Computing Environment


OSF Distributed Management Environment


Open System Interconnection


Private Branch Exchange


Pretty Good Privacy


Public Key Infrastructure


Quality of Service


Quadrature Phase Shift Keying


Remote Database Access


Radio Frequency Identification


Remote Procedure Call


Supply Chain Management


Secure Electronic Transaction a security standard


Simple Network Management Protocol - TCP/IP Network management Protocol


Simple Object Access Protocol part of Web Services


Synchronous Optical Network


Structured Query Language


Secure Socket Layer


Transmission Control Protocol


Transmission Control Protocol/Internet Protocol


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


User Datagram Protocol - a protocol that runs on IP


Universal Mobile Telecommunication System (Mainly 3G Cellular Technology)


Ultra Wideband


Value-added Network


Virtual Private Network


Voice eXtensible Markup Language


Wide Area Network


Wireless Application Protocol


Wireless Local Loop


Wireless Markup Language


Web Services


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.



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


  • 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


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







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





  • 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




  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




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



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?


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?


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


How will you avoid this?


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




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?




Start Date

When will the project start?

End Date

When will it end?


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:




Project Manager:




Department Manager:






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:






Prepared By









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.





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 :



Finished Date :



Project Manager :



Contact Number :






Project Goals & Objectives

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










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:




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






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











Delivery Method





















Delivery Method





















Delivery Method





















Delivery Method





















Delivery Method












Procurement Management Plan



Needed By(date)

























Project Statement of Work

Project Name:





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:












Project Management Deliverable




Step 4 :Monitoring & Control

Project Status/Progress Report


Project Title :






Reporting Period

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


Team Member






Work Completed



Work next reporting period






Suggestions /Issues



Project Changes




Step 5 :Closing

Client Acceptance

Project title:


Project Manager

















Project Lesson Learned

Project title:




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.


  • 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



Assurance Activity


Responsible Entity


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.