Part 4: Tera-Scope Contracts – Value Add or Gordian Knot?

In Parts 1, 2 and 3 of this series we have looked at the trend for Federal Information Technology (IT) procurements to enter into “Tera-Scope” contracts where all possible IT goods and services are brought under one massive Performance Work Statement.  Some Agencies are requesting all-or-none responses which are impossible for any one company to meet alone.  This adds further to the complexity by necessitating Teaming Arrangements that create groups capable of meeting all the task areas, experience requirements and socio-economic requirements of the RFP.  Some Agencies are creating their Tera-Scope RFPs but allowing companies to participate only in those areas representing their core competencies.  This simplifies the proposal writing process for the contractor and the evaluation process for the Government.

Ultimately a set of contracts will result that can be used by the target customer groups within an Agency, or even Government-wide, for ordering.  In Agency specific scenarios, the resulting contracts are promised to be the only vehicles to be used for any Agency requirement.  Project Managers must work with a company or a Team that has one of the contracts under the Tera-Scope.  Work may be competed only among those companies or Teams that have one of the contracts under the Tera-Scope.  Let us hope the Source Selection Team has chosen wisely and avoided protests from the losing companies.

What does the Government believe will happen when it limits its buyers’ access to companies that provide goods and services?

Winning companies should provide better prices just because they know they are more likely to get work now that the competition has been narrowed (aka Strategic Sourcing).
Winning companies should continue to provide better and better prices because they have to compete within this smaller pool to […]

Part 3: Tera-Scope Contracts and Risk

In Parts 1 and 2 of this series we talked about the contractor and Government perspectives of setting up for, releasing and responding to a Tera-Scope contract opportunity.  Now let’s talk about the high risks associated with putting together such a complicated contractual arrangement.

For several decades the Federal Government has employed Long Term Contracts in order to found relationships with a vendor or vendors for a long period of time.  Task orders are issued against the contracts for work as needs arise.  This saves the Government from repeating the full acquisition process over and over.  Sometimes only the founding Agency can order from the contract.  If ordering is open outside the founding Agency it qualifies as a Government-Wide Acquisition contract (GWAC).   I’m calling a Tera-Scope contract a Long Term Contract where the Government combines every conceivable IT service under one umbrella that requires each offeror to respond to all task areas.  This necessitates Teaming in order to present an excellent proposal in every regard.  For Tera-Scope opportunities where you must respond to all task areas a company cannot afford to be “just okay” in any one of them.  The main difference for a Tera-Scope is that the range of tasks included is very broad – even vast.

In responding to a Tera-Scope RFP proposals must detail why a Team is high quality and high value for every aspect of the Tera-Scope.  Once everything is written and submitted it may still be a while before a decision is made by the Government.  A recently publicized Tera-Scope draft RFP comes with a timeline of 12 months for evaluation and selection of teams for award.  Make sure you understand the termination provisions of your Teaming Agreements. You don’t […]

Part 2: Tera-Scope IT Contracts

In Part 1 of this series we talked about the trend towards “Tera-Scope” competitions within the U.S. Government for comprehensive Information Technology (IT) services.  Here in Part 2 we will take a peek under the tent at what the Government is going through.

Many groups that are often perceived as different business areas have collaborated on the PWS for this Tera-Scope contract.  Contributions for task areas have to give enough information about that area to foster understanding of the possibilities without getting too specific about what work will or won’t be ordered, so there can be no perceived promises.  Someone should be reviewing the whole package for consistency, duplication and conflict resolution.  Often this is left to the contracting folks who are not technical experts.  The evaluation criteria must give clear guidance to offerors and evaluators on what the Government needs to know to choose the right Teams.  All of the RFP requirements are pulled into a very large package that undergoes a series of pre-solicitation reviews to make sure the RFP is coherent, compliant and will result in a contract that achieves the Government’s objectives.  It depends on the organization and on the specific individuals involved as to how much conversation takes place between the requiring activities and the contracting activity before the RFP hits the street.  More is better, but more takes longer and these days speedy contract awards are in high demand.  There can be a tendency for a “you take care of your part and I’ll take care of my part” scenario to develop between the requiring activity (the IT Department) and the procurement activity.  There are not too many more frustrating things than re-explaining your requirements to your contracts specialist after […]

Part 1: Is the Trend for Tera-Scope Terrifying or Terrific?

In this 4 part post we are going to explore a trend in how the U.S. Government is acquiring Information Technology (IT) services. More and more agencies are developing Performance Work Statements (PWS) with every possible type of IT service (including associated item acquisition) into comprehensive, umbrella arrangements. There are several variations on this approach but the most current one seems to be the “all inclusive package”. In Part 1 of this post we are going to look at how vendors perceive what I am calling “Tera-Scope” opportunities.
Old Way: The Government needs a specific set of IT services over a multi-year period of time that will accomplish one large overall objective (such as the full life cycle of a computer business system). Companies 1, 2 and 3 compete. Company 2 wins the contract. Company 2 hires subcontractors to fill capacity or skill gaps and begins working with the Government to achieve the Government’s objectives. Next month the Government needs another specific set of IT Services over a multi-year period of time (let’s say it’s Help Desk/Customer Care). Companies 1, 4 and 5 compete. Company 4 wins the contract. Company 4 hires subcontractors to fill capacity or skill gaps and begins working with the Government to achieve the Government’s objectives. And so on…., resulting in a lot of contracts to manage.

New Way: The Government writes a “Tera-Scope” Performance Work Statement (PWS). It covers every aspect of IT services and products including property acquisition and installation, facilities management, operations, software development and sustainment, systems engineering, technology assessment, information assurance, help desk/customer care, training, administrative support and the kitchen sink. Only winners of a contract will get work within the Tera-Scope from that Agency. Any of the […]

  • Blog Images_SDLC 3
    Permalink

    Part 3: Software Development Life Cycle — The Solution Design

Part 3: Software Development Life Cycle — The Solution Design

The Solution Design stage begins upon Customer and stakeholder approval of the System Requirements Review (SRR) and its associated artifacts. Solution Design is specific to Scrum projects only. Design is not typically required for Kanban process cycles involving Problem Reports and smaller “break-fix” tasks. Partnet’s Solution Design stage consists of two elements: functional design and technical design.

Functional Design: User stories form the basis for functional design and planning. User stories are short, textual statements corresponding to a specific feature or business need that the software solution must fulfill. Requirement Managers write user stories based on the approved solution requirements. During functional design, user-story reviews are convened with members of the Delivery Team to formally discuss each user story in detail and specify its acceptance criteria. All outstanding questions and assumptions are documented for follow-up with the Customer and other external stakeholders. User stories are then allocated into specific development tasks and subtasks that constitute the Product Backlog.

Technical Design: In parallel with user-story reviews, our development and engineering group prepares the technical design solution. Aspects of the technical design include:

Analysis of necessary changes to the general solution architecture.
Review new interfaces for third parties.
Protection of system security posture.
Identification of required hardware components, operating systems, and network architecture.
Research supporting software technologies and libraries.
Determination of necessary changes to the data model(s).

Partnet convenes an internal design review to collect and incorporate final feedback on the designed solution from Software Developers, Test Engineers, Configuration Managers, Project Managers, security specialists, and support staff. This review focuses on specific items affecting the solution design, such as:

Ensuring the design minimizes development and maintenance costs.
Identifying opportunities for business-user configuration (i.e., administrative utilities that allow the Customer to configure and manage the software without new […]

  • SDLC P2
    Permalink

    Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Part 2: Software Development Life Cycle — Incorporating New and Emerging Requirements

Partnet’s development team understands that requirements are volatile by nature and are inevitably subject to change during the course of development. New and emerging requirements often occur as the result of unforeseen constraints, capability gaps, user implications, or newly-identified stakeholders. Our Agile methodologies provide the flexibility required to quickly and responsibly react to such changes without putting other priorities at risk.

New and emerging requirements should be presented to the Partnet development team by the customer in the form of a new or updated functional specification. Our Requirement Managers follow industry best practices to thoroughly assess all new requirements. Careful business analysis is performed to:

Determine any impacts to the existing system.
Identify the best implementation approach.
Mitigate risk to the customer and end users.

Upon identification of a new requirement, Partnet will work with the customer to define business objectives and desired outcomes. Requirement Managers will carefully assess the new requirement against the deployed defined or existing solution to:

Identify capability gaps.
Assess impact to current functionality.
Identify affected stakeholders.
Identify transition requirements.
Document risks and constraints.

Partnet Requirement Managers will present this assessment in the System Requirements Review (SRR). The SRR will document the stated, unapproved requirements along with a recommended implementation approach. Also, the Partnet Project Manager will identify the estimated cost and time necessary to implement the new requirement. Once the additional cost and time are approved by the customer, Partnet will follow its standard requirement procedures elicit, refine, and formalize the solution requirements. Requirement Managers thoroughly maintain requirements traceability to ensure that substantive changes are documented and versioned as new requirements are incorporated into the designed solution.

Partnet expects the customer to be a key stakeholder in the gathering and approval of all requirements—including new and emerging requirements. Consequently, the customer […]

  • SDLC Gears
    Permalink

    Part 1: The Importance of a Defined Software Development Life Cycle

Part 1: The Importance of a Defined Software Development Life Cycle

I’ve been thinking lately about how important it is for a company to have a well-defined process for the Software Development Life Cycle, or SDLC as we like to call it. I’m going to do a series a blogs to share our SLDC process.

Partnet’s SDLC employs industry-best practices in accordance with Agile principles and methods. Our approach ensures that the right product is delivered in the required time frame, while providing visibility into the solution’s development. As part of our Agile Development approach, we employ both Scrum and Kanban methodologies.

Partnet’s SLDC is a multistage process. The first step in the SDLC is to make sure that each development projects start with stable, well-defined requirements. Our Requirement Managers use industry-best requirement management practices as defined by the Business Analysis Body of Knowledge (BABOK).

The requirements manager coordinates and schedules requirements gathering activities with each stakeholder group. These activities may take the form of interviews, video teleconferences, requirement workshops, questionnaires, or other forms of outreach. In some cases, multiple rounds of requirements gathering activities may be required as the results are documented and consolidated.

This step ends with the preparation of a formal requirements package. The requirements package describes desired outcome(s), assumptions, and constraints associated to a given business requirement. A requirements package may be presented in any number of formats, including but not limited to:

Functional specifications
Screen mockups and page wire frames
Flowcharts, sequence diagrams, data flow diagrams and other visual models
Data dictionary
Use cases and scenarios
User Roles
Goal or desired outcome
Benefit to the customers and stakeholders

The Partnet team completes the Requirements Step by meeting with the customer and other stakeholders to conduct a formal System Requirements Review. This involves distribution of the requirements package(s) for stakeholder approval. Signatures are collected […]

Category Management in Federal eCommerce

Category Management is a way to present a group of like items, generally from a functional perspective, in such a way that the individual kinds of items in the category are listed and described, and their relationships and uses are also cataloged and explained in detail.

Organizing materials in such a fashion is essential for eCommerce sellers in order to support buyers who browse when shopping. Browsing provides the opportunity to understand all the options and enables informed, best-value choices.

A category will consist of an overarching designation: the title of the category. Within this grouping the subcategories can be listed in a branch-like fashion to show their relationships in relation to the entire category.

Here’s an example:

Office Supplies

Paper

White Copy Paper

By weight
By size
By package quantity
By brand
By finish
By price

Multi-Purpose Paper

Color Paper
Recycled Paper…

Writing Instruments
Fasteners
And so on …

Office supplies are ubiquitous and therefore a good category to illustrate the principle of subcategories. Even young students have a basic understanding that there are various items involved in doing activities at school that comprise “supplies” needed to support the learning process. Taking that further, they can distinguish between like-things that are used to write or draw with, things that are used to write or draw upon, things that are used to store or display the items written or drawn upon, and things that are used to change or repair those items; and yet see all of these things as related to each other.

Admittedly, there are some who know more about office supplies than others. For most people, a plain white sheet of 8.5 x 11-inch paper is “copy paper.” Little notice may be given to weight, content, density, manufacturing process, or stability by the average paper user, but for the connoisseur these […]

Are Government Agencies Drowning in Data?

Recently Federal Computer Week featured an article entitled: Why agencies are drowning in data. The article was based on a recent survey by Semantic Corporation on effective big data strategies. The survey found that that the main reasons for agencies feeling overwhelmed were data governance and data security. I think, however, they were asking the wrong questions.

The government is currently producing and making available huge amounts of data. I agree that this data needs to be kept secure and managed so it can be made available to the appropriate users. However, I think the bigger question is who is taking the time to look at the data and what are they doing with the information. Take acquisition data, for instance. There are volumes of data about what the government is purchasing, who in the government is making the purchases and what they are buying. Government analysts could be asking questions like:

Are we getting the best price possible on specific commodities?
Does one agency negotiate better prices than other agencies?
Why don’t we all get those good prices?
Which contract vehicles are most cost effective?
Is lowest price always the best answer?
Do we get more returns on commercial items that were purchased due to lower prices?

The list could go on and on. The problem is that no one is really looking at the data — truly analyzing it. Analysis of this type is very common in the private sector as businesses try to understand where they fit in a marketplace and how to make their supply chain run more efficiently. Government employees do not look at themselves as running a business.  They are always looking for cheaper prices and more efficient business practices, but often do not have the […]

Better Buying Power 3.0 – More Emphasis on Best Value

Best value is often described as the tradeoff between cost and performance that provides the greatest overall benefit. However, the word tradeoff to some may imply that one must either sacrifice cost to increase performance or sacrifice performance to reduce cost. Partnet prefers to define best value as the optimal blend of quality and performance delivered at the lowest possible cost and in the least amount of time.

It appears that Frank Kendall, the undersecretary of Defense for Acquisition, Technology and Logistics agrees with us on our best value definition. In a white paper published on September 19, 2014, Mr. Kendall says that Better Buying Power (BBP) 3.0 continues with a shift in emphasis toward achieving dominant capabilities through innovation and technical excellence.

Although overall cost continues to be a concern for the DOD, BBP 3.0 puts a strong emphasis on innovation. A series of new initiatives are listed below under the topic of Incentivize Innovation in Industry and Government:

Increase the use of prototyping and experimentation.
Emphasize technology insertion and refresh in program planning.
Use Modular Open Systems Architecture to stimulate innovation.
Increase the return on Small Business Innovation Research (SBIR).
Provide draft technical requirements to industry and involve industry in funded concept definition to support requirements definition.
Provide clear “best value” definitions so that industry can propose and DOD can choose wisely.
Increase small business participation, including more effective use of market research.

As a small business we appreciate the acknowledgement that we an important part of the DOD Acquisition Cycle. As stated in the white paper, “Small businesses remain one of DOD’s most productive sources of innovation — in services as well as in products.”

Google+