| Acceptance Testing |
Acceptance testing is the formal process of testing a system to determine if the system meets the specific requirements and acceptance criteria and is ready for production. If the system meets all specified criteria, the system is "accepted" and released for implementation at all user locations. A formal Go/No-Go Decision is usually held at the end of acceptance testing. Often system acceptance is also associated with payment of the contractor.
 Acceptance Testing
|
|
Alternative Procurements
An alternative procurement is one which allows bidders to propose different approaches to a business problem. The project office selects a bidder based on the feasibility of the proposed approach and cost. In a traditional procurement, the solution is defined and cost is the primary evaluation factor. Due to the size and complexity of OSI projects, the alternative procurement process is used to procure/develop the main systems. An alternative procurement requires the approval of DGS and changes the timelines for submitting the FSR. |
|
|
Best Practices Support Group (BPSG)
The BPSG is a group of staff dedicated to the creation and maintenance of best practices for use by all projects in the Systems Integration Division. This website contains the collective work of the BPSG and the entire organization related to OSI Best Practices for System Acquisition. For more information on the BPSG, refer to the Links & Downloads section of the website. |
Bid Protests
Bidders may protest either solicitation requirements or the final contract award. DGS has the primary responsibility for addressing protests. Refer to DGS' State Contracting Manual and Purchasing Authority Manual for more information on responding to protests. |
| Bidders Conference |
A Bidders Conference may be held, during which bidders are afforded the opportunity to collectively meet with project personnel and discuss the content of the RFP and the procurement process. Notification of the time and place of such conference, if held, is made to all bidders receiving an RFP. The location should be sufficiently large to accommodate the anticipated pool of bidders.
Usually DGS conducts or assists with the conference. The procurement team provides assistance. Legal representatives may attend, as appropriate. The conference includes a discussion of the project objectives and system background, the bidding process, and key procurement dates. There may also be a discussion of potential conflict of interest situations to warn the bidders of any preclusion that may result from bidding or winning the contract from the procurement.
The bidders may ask bidding process questions (answered by DGS) and request clarification regarding the project background. Non-process questions (such as questions regarding RFP requirements) should be submitted in writing. Any questions received prior to the conference may be answered at the conference at the discretion of the project; answers must also be provided in writing to all bidders.
A transcript of the discussion, or those portions which contain the questions and appropriate answers, should be transmitted within approximately ten (10) working days to all bidders. If questions asked at the conference cannot be adequately answered during the conference, answers should be provided with the transcribed data. Oral answers are not binding on the State (bidders should be reminded of this at the conference). All answers are transmitted to all bidders, regardless of who asked the question; the identity of the source of the question is not divulged.
 Bidders Conference
|
|
Bidders Library
A Bidders Library is a resource for potential bidders during the procurement process. The library provides access to additional background or supporting materials that were referenced but not included in the RFP. The library is available to any bidder. DGS can assist with guidance on the setup of the library. Instructions for accessing the contents of the library must be included in the RFP.
The library should only include public, non-sensitive information. The procurement team should carefully review and select items for the library that are pertinent and useful, and of the appropriate level of detail and format for acceptable project documentation. The library is considered dynamic and may be updated until the final proposal evaluations are complete. Typical items which may be included in the library include policies or regulations, existing system documentation, interface specifications, project processes which the selected bidder must comply with, and metrics or statistical reports which will be required.
The Bidders Library should be available as soon as the RFP is released. The library may be handled manually (via paper), posted to a web site, or provided via CDROM. If the items are made available via CDROM, the RFP should indicate whom to contact to receive a copy. If an addendum updates the contents of the library/CDROM, the addendum should remind the bidders they will need to request an updated copy of the library CD.
If the Bidders Library is handled via paper, the procurement team will need to establish a secure location for the contents or the library. The location should be established in a location separate from the procurement team to ensure the bidder is not inadvertently exposed to procurement information or activities. Bidders must call a designated procurement representative to make an appointment to view the library (to ensure competitors are not trying to view the materials at the same time). Bidders may be required to sign-in and out of the library location. The RFP should indicate the name and phone number of the person to contact to view the library, the days/hours the library is available, and if the bidder may request copies of the materials and how much the project will charge the bidder to make the copies. At no time should the library materials be allowed to leave the library location (other than to make the copies). |
Budget Process
Each year, the OSI projects must request and secure funding and, if necessary, spending authority for their project. The budget and planning documents (Budget Change Proposal (BCP), Feasibility Study Report (FSR), Special Project Report (SPR)) are used by the Sponsor, Department of Finance, and the Legislature to review the project budget request. In some cases, requests for federal funding (via an Advance Planning Document (APD)) must also be submitted to secure federal matching funds. Typically, funding for the OSI Projects is included in the Sponsors budget and spending authority for the project is included in OSIs budget.
For more information on the budget process, refer to the State Administrative Manual (SAM), DOF website, or the Budget Process Overview (available to OSI staff in the iManage BPwebdocs repository). |
| Business Process Re-engineering (BPR) |
The purpose of Business Process Re-engineering (BPR) is to help prepare the users for the new or modified automated system that is being developed. The focus is on understanding and documenting current processes and business needs, and identifying where automation may help. Then the focus shifts to assisting users to modify or use new processes that incorporate the use of the automated system functionality. Training and measuring process effectiveness are important parts of the BPR/BPI effort.
The goals of BPR are to streamline existing processes, to ensure the correct processes are being automated (i.e., some processes do not need to be automated), and to ensure automation is addressing the process need. This does not mean the elimination of all manual processes. Some new processes may be a combination of manual and automated activities. In many cases, an organizational change or re-design may be part of the effort or it may be a simultaneous effort.
Note that although OSI uses the term "BPR" it is used in a generic sense. Most of what OSI does usually is considered Business Process Improvement (BPI) and not a true, full-scale BPR.
Business Process Reengineering (BPR)
|
|
California Multiple Award Schedule (CMAS)
The CMAS is a Leveraged Procurement Agreement which can be used to procure specific products or services. CMAS vendors are pre-qualified (based on past experience and customer recommendations) and must periodically renew their qualifications with DGS. CMAS transactions may not exceed $500,000. For more information, refer to the CMAS area of the DGS website. |
| Change Control |
Change control consists of the identification, analysis and disposition of a proposed change. Change control applies to many different project office functions (e.g. requirements management, project management, document management, contract management, etc.) as well as contractor delivered products. OSI considers change control to be a subset of configuration management.
Change Control
|
|
Change Control Board (CCB)
A Change Control Board is used to control identified system changes, review impacts, and grant approvals as part of the change management function. The CCB is typically comprised of members from project management, system architecture, quality assurance, systems engineering, as well as members from the program/business areas and contractors, if needed. |
Change Leadership
The activities performed to manage organizational changes including organization structure, roles and responsibilities, type of work performed, and management reporting. Focuses more on soft-skills to address personnel concerns and to change organizational culture and perceptions. Contrast this definition with Change Control and Change Management. |
| Closeout |
Reference material from the old BP website
Closeout
|
|
Closing the Contract
When a contract comes to a close or is terminated, it is important to review the contract and Statement of Work to ensure all products and services have been delivered, and to review any payment withholds, liquidated damages or performance bonds which may affect the final invoices or payments. Some contracts include specific termination clauses which affect payments and disposition of equipment.
The project office must also complete a contractor evaluation using DGS Standard Form 4, particularly if the evaluation is not favorable. Refer to the State Contracting Manual for more information on closing and terminating contracts (on the Navigation Menu to the left, select the Links & Downloads option and go to the State page to find direct links to the Manual and to the DGS Froms Management Center). |
|
Conflict of Interest
All project staff and contractors must evaluate their potential for conflict of interest when working on a project. Conflict of interest occurs when project decisions affect the financial interests of the employee, their family or their company (if appropriate). In addition, staff members must be aware that they must keep sensitive procurement information confidential. This is a particularly complex issue with severe legal ramifications for infractions. For more information consult your procurement manager. |
| Consultant Acquisition |
Consultants who assist the project office generally are acquired through the use of the state’s Leveraged Procurement Agreements, such as CMAS and MSA. However, if the scope of work is significant a competitive bid may be more appropriate.
In most cases, consultant acquisitions focus on services and a few key products. It is important to choose a payment method and sufficient deliverables to be able to monitor the progress of the work effort (i.e., having deliverables due towards the end of the contract introduces a greater amount of risk). Frequent status reports and interchanges are important since it is difficult to identify meaningful metrics for services.
Consultant Acquisition
|
|
Contract Amendments
A written change to the terms or scope of work specified in the contract. Contract amendments must follow the same review and approval processes as the original contract. A contract amendment is required whenever there is a change to the contract dollar amount, contract end date, scope of work, or key contractor personnel. |
|
| Contract Payment Strategy |
There are various types of contract strategies which employ different approaches to terms and payment strategies. In general, there are fixed price contracts, cost reimbursable contracts and time-and-material contracts. In addition, contract incentives and/or penalties may be included.
Contract Strategy
|
|
Contract Types
In general, OSI uses three primary types of contract vehicles for procuring goods and services: the California Multiple Award Schedule (CMAS), Master Services Agreement (MSA), and the competitive bid.
Other types of solicitation documents are available depending on the needs of the project. Consult with DGS to determine the appropriate solicitation and contract type for the procurement. |
Contractor Evaluations (DGS STD Form 4)
At the close of a contract, the project is required to complete a contractor evaluation form (DGS STD Form 4) describing the performance of the contractor. The form must be submitted within 60 days of the close of a contract, particularly if the evaluation is not favorable. Refer to the State Contracting Manual. |
| Contractor Invoices |
Contractor invoices are paid only after the appropriate services and/or deliverables have been received and approved by the project office. The project must review and approve invoices in accordance with the state’s Prompt Payment Act. In the event of a invoice dispute, the contractor must address the issue and may need to submit a corrected invoice.
Contractor Invoices
|
|
Cost of Quality
Cost of quality refers to the cost of all efforts to achieve product/service quality, and includes all work to ensure conformance to requirements, as well as all work rsulting from nonconformance to requirements. There are generally three types of costs that are incurred: prevention costs, appraisal costs, and failure costs. |
Cost-Benefit Analysis
Cost-Benefit Analysis (also called benefit/cost analysis) involves estimating tangible and intangible costs (outlays) and benefits (returns) of various project and product alternatives, and then using financial measures, such as return on investment or payback period, to assess the relative desireability of the identified alternatives. |
Data Conversion
In some cases, an OSI project involves implementing a new system to replace an existing system. If there is an existing system, the existing data generally must be migrated to the new system. This generally involves mapping the existing data to a new format and structure. Often the data must be reviewed and "scrubbed" to correct anomalous or specially coded data fields. Data conversion may also be appropriate in the M&O phases if there is a change to the database.
Data conversion employs a combination of automated and manual processes. Automated processes can be used to speed the effort, but past experiences have shown that automated processes will only be 75% effective at best. Be sure to provide sufficient budget (cost, schedule, resources) for manual data cleansing. |
Defect Tracking
Usually referred to as Problem Tracking and Management. This process involves the identification, analysis, tracking, and resolution of concerns or issues with the automated system and/or system documentation. Typically, a help desk would collect system problems and manage the eventual resolution. |
| Deliverable Expectation Document (DED) Reviews |
|
|
| Deliverable Reviews |
Contractor deliverables are reviewed against the appropriate requirements from the contract, SOW and/or DED or DID. The Contract Manager or Functional Manager facilitate the review and enlist the assistance of appropriate subject matter experts to ensure the deliverable is clear, consistent, usable and meets the specified requirements. If a deliverable is not acceptable, the deficiencies and comments are forwarded to the contractor for correction. The contractor must submit an updated/corrected deliverable and the review process begins again.
Deliverable Review
|
|
Deliverables
A work product produced by a contractor or consultant in accordance with the terms of their contract. Contrast this term with Work Products. |
| Escalation |
Reference material from the old BP website
Escalation
|
|
| Functional Testing |
A type or phase of testing which focuses on functional groupings of the system which are logically related. Also verifies interfaces between related modules and utility or generic modules or functions.
Functional Testing
|
|
Go/No-Go Decisions
Critical decisions which occur at key project milestones to review project and/or contractor progress. Each Go/No-Go Decision has key criteria which must be met in order for the project/contractor to progress to the next phase or stage. The Go/No-Go Decision is a formal decision made by the project manager, sponsor and appropriate executives or stakeholders. If the decision is “No-Go”, a list of specific action items are documented which must be completed before the project/contractor may move to the next phase/stage.
An example of a Go/No-Go Decision is county readiness for implementation. If a county has not completed all activities required for a successful implementation, the decision would be “No-Go” until the remaining activities were completed. |
| Help Desk |
An organizational unit and function which helps users address problems or questions regarding the use of the system. The help desk attempts to resolve the issue if possible. If the issue cannot be resolved it is escalated to the appropriate organization (e.g., network specialist) or process (e.g., change request process) for resolution.
The help desk also assists the project by providing insight into user opinions on the system and by helping to identify problem trends which may point to a need for better training or documentation, or re-design of a system screen or workflow.
The prime contractor may be responsible for the help desk (either directly or through a subcontractor) or the project may elect to operate the help desk. Note that there may also be a separate help desk for project office staff which is operated by the project's IT staff and assists with the problems and questions regarding the project office infrastructure.
Help Desk
|
|
|
| Implementation Function |
Implementation describes the activities required to release the new system/system release to the user community. Often, this involves installations of hardware and/or software at multiple locations. The Implementation function includes several activities including site survey, site preparation, installation and checkout, pilot testing, and pilot evaluation. It may also include such activities as Business Process Re-engineering, Change Leadership, Data Conversion, and User Training.
Implementation is also considered a life cycle phase that describes the collection of implementation functional activities at each individual production location.
Implementation
|
|
Independent Project Oversight (IPOC)
An independent vendor hired to monitor the efforts of the project office to manage the project. The IPOC generally is hired and reports to the project Sponsor. The IPOC focuses specifically on the project management practices of the project office and particularly risk management. See also Independent Verification and Validation. |
| Independent Verification & Validation (IV&V) |
An independent vendor hired to monitor the efforts of the prime contractor to ensure the system and associatd products comply with the state requirements and address the original business need. The IV&V generally is hired and reports to the project Sponsor. IV&V focuses specifically on the system products and the project office management of the products and their development. See also Independent Project Oversight Consultant (IPOC).
Independent Verification & Validation (IV&V)
|
|
| Integration Testing |
A type or phase of testing which focuses on verifying functional groups, inter-function interfaces, external interfaces, and business and user workflows and scenarios.
Integration Testing
|
|
| Interface Testing |
A type or phase of testing focusing exclusively on the testing of external interfaces. May be conducted as part of Integration and/or System Testing. These tests require special coordination with external organizations and frequently involve special test setup or special test environments.
Interface Testing
|
|
| Issue and Action Item Tracking |
The purpose of Issue and Action Item Tracking is to ensure the proper oversight and management of unanticipated or unplanned issues or actions that arise throughout the project lifecycle for which advanced planning is not possible. When an issue is identified, it should be analyzed to determine the cost, schedule, resource (personnel, facility, equipment), risks, political, and reputation/relationship impacts. These criteria should be used to help prioritize and quantify effects to the project. The analysis should consider impacts both if the issue is and is not resolved and/or impacts for various resolutions.
Generally, issues can be any unplanned task needing resolution. Action items typically are associated with an issue and are specific tasks with assigned staff and due dates that relate to completing or resolving the issue.
Issue & Action Item Tracking
|
|
Key Questions for the Initiation Phase
When preparing to present a project concept for approval, there are several questions which should be considered. These questions help the executives determine if the investment in the project is justified and if the organization is able to execute the project. Note: The answers to these questions will also provide input to the Project's Charter.
[ ] Is this project consistent with the department AIMS/enterprise and IT Strategy and Vision? How the does the project meet the business needs of the department?
[ ] What is the Goal of the project? Why does it have to be started now?
[ ] Who is the Sponsor? Are they prepared to commit time and resources to this project? Do they understand what their role will be and what their responsibilities will be?
[ ] How much Staffing will it require? Are staff with the appropriate Skills available? Is there adequate project management staff for this project?
[ ] Who will Support the project once it is complete? Is the M&O staff experienced in this technology/application already?
[ ] How much will it Cost and what is the Benefit? Why should this project be funded as opposed to other projects? What is the return on investment? What is the impact or penalty of not performing this project? Is funding available?
[ ] What is the anticipated Length of the project? How will this impact other projects and operations currently underway or planned? Will this project still be necessary in a few years or will it be obsolete? What are the impacts if the project is late or delayed?
[ ] What is the Priority of this project when compared to other projects or initiatives, both planned or in progress?
[ ] What is the Probability of Success? Does the organization have experience with the technologies and type(s) of software that will be involved? |
| Legislative Process |
Legislation may initiate or affect a project. In addition, a project may initiate or attempt to influence proposed legislation for consideration. Legislation can be used to change policy or in some cases to impose deadlines or restrictions to assist a project. Legislation is introduced via a bill that must be reviewed and discussed in the State Assembly and State Senate. If both houses approve the bill, it is sent to the Governor for signature and then to the Secretary of State for chaptering and enactment. For more information on the legislative process, refer to the Citizens Guide to a Lifecycle of a Bill on the State Capitol's website.
Legislative Process
|
|
| M&O Change or Enhancement |
These requests involve a change to the current requirements and operations of the system or an enhancement of existing system capabilities. Changes and enhancements may come from a variety of sources including user requests, new legislation and regulations, and new technologies and system upgrades.
Changes and enhancements are reviewed and approved through the change control process. A thorough cost and impact analysis must be performed to ensure the project has the resources to accomplish the change and to ensure the change will not negatively impact the system, other project initiatives, or other system stakeholders. Changes must be carefully prioritized due to budget constraints.
M&O Change or Enhancement
|
|
M&O Strategy
The M&O strategy defines the general approach for maintenance and operations activities. The intent of the M&O Strategy is to identify the assumptions and establish the framework for the M&O section of the Request for Proposal and for the ongoing M&O phase. The Strategy should identify the activities the bidders should address in their proposals and to re-affirm within the organization the strategy to be used for M&O activities once the project is completed.
The strategy should define how the project office expects to divide M&O responsibilities between the state and contractor(s). Once the contract is awarded, the contractor and/or state will develop a detailed M&O Plan that must be consistent with this strategy.
Typical M&O issues include:
-- M&O Responsibilities: Who is responsible for performing what activities? Consider the following organizations: project staff, DTS operations staff, OSI staff, prime contractor, subcontractor, county staff, sponsor staff, outsourced consultants.
-- Transition Activities: Once the system is put into production, who has the primary responsibility for the system? Is the prime contractor initially responsible as part of the acquisition contract? If not, how will the transition of responsibilities be performed?
-- Training: If the prime contractor is not responsible for the M&O activities, has sufficient time and training been provided for each of the staff and staffing levels? What are the State and Contractor's roles for training on the new system? What are the user classes? How many people will need training in each class? What type of training will they need? Is on-the-job training and mentoring included to allow hands-on learning?
-- Knowledge Transfer: If the prime contractor is not responsible for the M&O activities, have sufficient time and opportunities been provided for each of the staff and staffing levels to learn from the contractor? A period of 6-12 months is generally recommended so that staff may experience a complete year's processing including peaks/valleys and end of the year processing activities.
-- Change Control: How will changes to the system be handled? What is the process and how are each of the participants involved? Who is responsible for analysis and approvals?
-- Day-to-Day Operations: How will day-to-day operations be handled and by whom? What is the process and who is responsible for resolution of any problems?
-- Maintenance: How will maintenance activities be handled and by whom? What is the process and who is responsible for scheduling and notifications of the work? |
Master Services Agreement (MSA)
The Master Services Agreement is a Leveraged Procurement Agreement which can be used to procure specific products or services. Interested vendors are invited to bid on the MSA every few years. Selected vendors are placed on the MSA list and are considered pre-qualified to provide the specific category of services or products. Currently the MSA limit is $500,000, but an exemption to the limit may be requested from DGS. For more information, refer to the Master Agreement section of the DGS website. |
Milestone Review
A review session conducted when the project or contractor believe they have reached a key defined milestone in the project or system development. Criteria for the milestone are reviewed and results of the phase or stage are summarized. Key deliverables are reviewed and must be approved prior to milestone completion. In some cases, a Go/No-Go Decisions is conducted to formally authorize the project/contractor to continue to the next phase/stage in the life cycle. |
Notice of Intent to Award
After selecting a winning bidder, the project must post a Notice of Intent to Award to the public. After the notice is posted, the contract cannot be awarded for a period of five days. This allows all bidders to review the selection and evaluation results. Refer to the State Contracting Manual on posting and notification requirements. |
OSI Projects
OSI Projects refer only to projects of a statewide nature (e.g. CWS/CMS, CMIPS, EBT, ISAWS, SFIS, etc.) and not to software release projects that are part of a routine Maintenance & Operations life cycle, or internally created projects and initiatives. |
OSI Training
OSI Training is training that is "common" to all projects, unlike project training which is "specific" to the unique needs of the project. OSI Training is high-level and planned in accordance with the MSC-generated annual OSI Training Plan. |
Payment Methods
There are two methods generally used by the state for contract payment.
Fixed Price - Under a fixed-price contract, the contractor agrees to deliver the product or service required at a price not in excess of the agreed-to maximum. Fixed-price contracts should be used when the contract risk is relatively low, or defined within acceptable limits, and the contractor and the state can reasonably agree on a maximum price. Payment is made when the specific work product is delivered or at the completion of the contract.
Time and Materials - Labor-hour and time-and-materials contracts both include fixed labor rates but only estimates of the hours required to complete the contract. The total number of hours allowed is capped at a maximum amount, or the total cost of the contract may be capped. Contractors should be required to produce a Spending Plan or Task Accomplishment Plan that describes the rate and plan for expending hours/dollars by month for the length of the contract. This allows the project to monitor the rate of expenditure to ensure the contractor is producing adequate progress/products for the amount of money paid. |
| Performance Testing |
A type or phase of testing which focuses on evaluating the system's performance capabilities against the specified requirements. May also include stress testing and worst case scenario testing.
Performance Testing
|
|
Phase Launch Meeting
A phase launch meeting is conducted at the beginning of a new life cycle phase to help focus the project office on the new activiites and goals of the phase. Often this includes a review of lessons learned, orientation to new processes, review of roles and responsibilites, and introduction of new workplans and assignments.
Phase launch meetings generally are facilitated by Project Management and include project office staff (state and consultants), and may include prime contractor staff, if deemed appropriate. |
Phase Readiness Reviews
Phase Readiness Reviews are mini project reviews designed to assist project teams in preparation for a new life cycle phase. The BPSG facilitates these reviews on behalf of the project with a review of such things as lessons learned (from a similar project past), newly created policies, templates, and/or guidelines that might be applicable at the time of the readiness review.
Refer to the Phase Readiness Review folder in the OSI iManage Repository for guidance and samples of the latest phase readiness reviews. |
| Pilot Testing |
A type or phase of testing which verifies the system in the users actual environment. Generally involves verification of both the system and business processes under typical business conditions. The RFP should indicate the requirements for pilot testing and how pilot testing will be performed and evaluated (e.g., is there one pilot test or multiple pilot tests, is there a Go/No-Go Decision associated with each pilot, what criteria are used to determine if the pilot was successful, etc.).
Pilot Operation Final Review
A type or phase of testing which verifies the system in the users actual environment. Generally involves verification of both the system and business processes under typical business conditions. The RFP should indicate the requirements for pilot testing and how pilot testing will be performed and evaluated (e.g., is there one pilot test or multiple pilot tests, is there a Go/No-Go Decision associated with each pilot, what criteria are used to determine if the pilot was successful, etc.).
Pilot Testing
|
|
Private Legal Counsel
In some cases, the project may wish to engage private legal counsel to advise the project on specific industry topics (e.g., electronic benefits). The use of private legal counsel must be approved by the State Attorney General. The project must clearly define the tasks and scope of work for the private legal counsel to avoid conflicting or duplicate tasks with state/sponsor legal counsel. Refer to the State Contracting Manual for more on contracting for legal services. |
| Problem Report/Trouble Ticket Tracking |
This process involves the identification, analysis, tracking, and resolution of concerns or issues with the automated system and/or system documentation. Typically, a help desk would collect system problems and manage the eventual resolution. Sometimes called Defect Tracking
Problem / Defect Tracking and Resolution
|
|
| Process Improvement |
The attached documentation is reference material from the old BP website.
Process Improvement
|
|
Procurement Delegation
The California Department of General Services is responsible for conducting all procurements within state government. In some cases, projects may request delegation of procurement authority to the project for a specific solicitation. All applicable state rules, regulations and processes must be followed. Only the approval process and level of DGS involvement changes. For more on procurement delegation, refer to the purchasing authority area of the DGS website. |
| Procurement Feasibility |
The attached documentation is reference material from the old BP website.
Procurement Feasibility
|
|
|
Project Infrastructure List
Infrastructure needs for a project can include facility space (including power and security), cubicle and office furniture, phones and network connections, computing hardware and software, office machines (such as copiers, faxes), and mail services. Infrastructure items are managed by the Administrative Management team. |
|
| Project Strategies |
The attached documentation is reference material from the old BP website.
Project Strategies
|
|
Project Training
Project Training is training that is "specific" to the unique needs of the project, unlike OSI Training which is "common" to all projects. Each project is responsible for developing a Project Training Plan. Refer to the OSI Policy on Training for more information on expectations and requirements for this topic. |
Property Transfer Reports
Property transfer reports are DGS forms used to transfer project equipment (Property Transfer Report STD 158 Form) or documents (Records Transfer List STD 71 Form) to other organizations, typically at the end or termination of a project (on the Navigation Menu to the left, select the Links & Downloads option and go to the State page to find a direct link to the DGS Forms Management Center). |
| Quality Assurance |
The attached documentation is reference material from the old BP website.
Quality Assurance
|
|
Records Retention
Records retention is the process of deciding which documents will remain and which documents will be destroyed after a determined amount of time. The project librarian is typically responsible for managing the life cycle of documuments and describes the process in the Document Management Plan. |
| Regression Testing |
A type or phase of testing involving the re-execution of previously approved tests to ensure the test results are the same as when last executed and that the recent changes/fixes have not adversely affected the system. Regression testing may be performed at the end of each test phase (after all fixes for that test phase have been incorporated), or as a separate test phase prior to System and/or Acceptance Testing.
Regression tests utilize the exact test data and procedures/scripts as in prior test phases and should cover all areas of the system, not just the areas which were changed/fixed.
Regression Testing
|
|
| Request for Proposal (RFP) |
The solicitation document typically used for the prime contract procurement. The format is dictated by DGS regulations and the State Administrative Manual (SAM).
Request for Proposal (RFP)
|
|
| Requirements Management |
The attached documentation is reference material from the old BP website.
Requirements Management
|
|
|
Requirements Traceability
Requirements traceability deals with ensuring all requirements have been fulfilled in the end product. Bi-directional traceability (tracing both to a source and subsequent work products) is essential for ensuring only the desired functionality has been implemented. Backwards traceability involves verifying the source of the requirement. Typically this is legislation, regulations, business policy or user needs identified from a workgroup session. Requirements from the RFP and contract are traced forward to the contractor's design, code and various levels of testing documents.
See also Requirements Management. |
| Risk Management |
The attached pdf document summarizes this topic as originally captured on the old OSI Best Practices website. Note: Not all of the links are active. The links surrounded by a box provide hyperlink capabilities within the document.
Risk Management
|
|
|
|
Section 11 Notification
A provision in the Budget Act that requires DOF approval and a 30-day notification to the Legislature prior to executing a contract that exceeds a certain dollar threshold and for which the costs have not been approved through the budget process. Because most OSI projects use the alternative procurement process (where the development and implementation costs are not known until a vendor is selected), most OSI projects need to submit a Section 11 prior to contract award. A worksheet is available on the DOF website to determine if a procurement is subject to Section 11 reporting requirements. The project contract and fiscal staff work with DOF to submit the notification to the Joint Legislative Budget Committee. If no response is received after 30 days, the contract may be executed. (For further information use the "Links & Downloads" option on the Navigation Pane to the left, select the State link category and choose the DOF Budget forms link) |
SEI Taxonomy-Based Risk Identification
The Risk Taxonomy is a questionnaire developed by the Software Engineering Institute (SEI) to aid in the identification of risks based around typical categories. The questions allow project teams to explore potential risks that they might not otherwise consider. See also the Links and Downloads>Industry>SEI Taxonomy-based Risk Identification link for a copy of the risk-based taxonomy questionnaire. |
Special Project Report (SPR)
An SPR must be submitted to DOF whenever a project change occurs or is being planned which would deviate from the project's approved FSR. Refer to the State Administrative Manual (SAM), Section 4819 et al; and the Statewide Information Management Manual (SIMM), Section 30 for more information. (For further information use the "Links & Downloads" option on the Navigation Pane to the left, select the State link category and choose the SAM and SIMM links) |
Stakeholders
Individuals and organizations who are actively involved in the project or who may be positively or negatively affected by the outcome of the project. Stakeholders may also include those organizations who oversee or exert influence over the project and its results (e.g., control agencies). |
State Administrative Manual (SAM)
The DGS document which describes the basic procedures and administrative requirements for state organizations. The manual covers a variety of topics including procurements, budgeting, accounting, telecommunications, and travel (on the Navigation Menu to the left, select the Links & Downloads option and go to the State page to find a direct link to the SAM and see sections 4800 and 5200 in particular). |
State Contracting Manual
A document produced by DGS which describes the processes and procedures for soliciting and managing contracts. Volume I of the manual focuses on contracts for services, interagency agreements and other items. Volume II of the manual (the Purchasing Authority Manual) focuses on delegated authority for procurements and procedures for delegated purchasing. |
| Status Meetings (for Contractor Implementation) |
The attached documentation is reference material from the old BP website.
Status Meetings
|
|
Strategic Planning
The Software Engineering Institute (SEI) uses the term Software Acquisition Planning (SA-CMM) to address long-term strategies for acquisition. OSI refers to this key process area as strategic planning. |
| System Testing |
A type or phase of testing which verifies the complete, integrated system meets all its objectives and requirements. All external interfaces are verified along with end-to-end business workflows.
The attached documentation is reference material from the old BP website.
System Testing
|
|
Test Standards
Testing standards are used to provide guidelines for minimum types of testing and test cases, and to ensure that all test materials are complete. Refer to IEEE 829 - Standard for Software Test Documentation. |
| Test Strategy |
The Test Strategy is used to help the project office clarify expectations with the user and sponsor (and contractor) regarding their obligations in the testing and acceptance of the new system in the user environment. The prime contractor may also prepare a Master Test Plan (as part of the contract) that describes their approach to all testing phases and the activities for which they are responsible.
The attached documentation is reference material from the old BP website.
Test Strategy
|
|
| Unit Testing |
A type or phase of testing in which the individual hardware or software units are verified to ensure they work correctly. The emphasis is on removal of basic coding and logic errors and to ensure the unit or item meets its lowest level requirements, especially error handling and outputs.
The attached documentation is reference material from the old BP website.
Unit Testing
|
|
User Acceptance Test
The purpose of the User Acceptance Test is for users to verify the system or changes meet their original needs. The emphasis is on evaluating the system via normal business circumstances, but in a controlled environment. |
User Training
User Training is a critical piece to the system implementation phase and should include (at a minimum) considerations in the following areas: Select which users will receive each type of training, develop user training schedule based upon type of training and number of users to be trained, and develop office coverage plans for user training period.
See also Implementation Function. |
Work Orders (authorizations)
Work orders are used to clarify a high-level scope of work in the contract/PO. One example of this is for a series of system releases for an M&O contract. In this case, the contract would require a certain number of system releases for a certain dollar amount over the period of the contract. A work order would be used to clarify which change requests, fixes and system upgrades would be performed in which release and would authorize the expenditure of a certain amount of funds. In this example (of an M&O contract), the work order is closely tied to the change control process. Work orders can also be used in a development contract for known legislation changes. In this case, the project may know that legislation that would affect the system is pending, but may not be able to identify affected areas/requirements. The status of the legislation may be tracked via an issue system or through the change control process. A certain amount of money could be set aside for a work order(s) that would allow the contractor to analyze impacts to the system, and then to make the required changes if the project manager determines it appropriate (based on cost, schedule and risk impact analyses). |
