Coder Social home page Coder Social logo

fitara's People

Contributors

aescottathome avatar benbalter avatar bsweezy avatar gbinal avatar jremes-foss avatar kbenkreira avatar konklone avatar malissal avatar ombegovrecords avatar repgerryconnolly avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fitara's Issues

Changing how URL works

Any thoughts on having management.cio.gov serve as an alias and not a redirect for whitehouse.github.io/fitara/? Along the same lines as playbook.cio.gov and project-open-data.cio.gov.

The term "Shadow IT" is polarizing (in a bad way)

The terms "Shadow IT" and "Hidden IT" are highly polarizing and serve only to alienate us from the mission partners we are trying to work closer with. You should replace the use of these terms with "Program Directed IT" or something similar. Having programs take a lead role in automating their mission and making it transparent isn't necessarily a bad thing.

Even on the private industry side, CIO's only control about 60% of the IT budget.
http://www.forbes.com/sites/tomgroenfeldt/2013/12/02/40-percent-of-it-spending-is-outside-cio-control/

I would hate for our mission partners to start referring to IT departments as a "Shadow Program" or "Hidden Mission."

Need for IT Spend Visibility Pathfinder Pilot(s)

The biggest gap in the draft guidance is the lack of any real guidance on how to effectively implement IT spend visibility across the Planning, Programming, Budgeting and Execution (PPBE) life cycle. In the Common Baseline, the authority is given to the:

  1. CFO and CIO to jointly define the level of detail with which IT resource levels are described
  2. CFO, CAO and CIO to define agency-wide policy for the level of detail of planned expenditure reporting for all transactions that include IT resources

Achieving effective visibility is a dauntingly difficult challenge. One need only try to fuse the data reported through OMB's IT Dashboard (investment planning/programming) to that reported through sites like USASpending.gov (procurement transactions linked to budgeting/execution) to see the tremendous gap in granularity that needs to be closed to be able to trace investments, let alone performance/results of those investments for the American public, through the PPBE life cycle. All agencies have to execute essentially the same life cycle, even though some may do it with widely different ways of distributing organizational authority and management due to the nature and culture of their agency. With the current guidance, the Federal government is almost guaranteed to achieve almost as many different variations in IT spend visibility success as there are agencies.

What is sorely missing from the guidance is an explicit requirement for establishing and executing one or more Pathfinder pilots to determine and converge on effective and common mechanisms to trace IT spend through the PPBE cycle to results and outcomes for agency missions. One way to establish this requirement could be by adding an action to the end of Section B for OMB to initiate its own pilot, potentially through the US Digital Service, and establish timelines for reporting the results through the CIO Council in its quarterly meetings. Another, or perhaps additional approach might be to require each agency CIO to initiate their own such pilot in Sections A1 and E1 of the Common Baseline, similarly establish timelines for reporting the results either to the CIO Council or to OMB directly, and converge best practices from those results to establish Government-wide standards for implementing IT spend visibility.

Making these changes to the guidance will actually give agencies a chance to successfully and more rapidly achieve the goals for more effective and efficient Government that Congress envisioned when crafting the FITARA legislation. As a note, though elements of the DATA act might be leveraged, the act is focused on achieving greater investment transparency at the award level, and not throughout the PPBE life cycle in a traceable and consistent manner.

Robert Damashek
CTO, Binary Group

Attachment E: fix outline formatting

For some reason the outline in Attachment E is appearing all on one line. It should look more like:

Management

  • Program/Project Management
  • Portfolio Management
  • Enterprise
  • Strategy
  • Financial Management

Adequate Incremental Development?

The definition of "Adequate Incremental Development" needs work, and at this point its definition should be delegated down to the agencies to define on their own.

"Adequate Incremental Development - For development of software or services, planned and actual delivery of new or modified technical functionality to users occurs at least every six months."

Some issues with this definition:

  1. The "... or services" portion should be dropped because the definition of services is usually labor-based, not technical functionality based. I'm not sure what I would tell the desktop support service staff regarding how to satisfy this requirement.
  2. Not all systems increments should be published to the users. Think about the F-35 flight control software, Healthcare.gov that had a mandated go-live date that was more than 6 months away, or large COTS replacement projects that would require lots of expensive scaffolding to integrate the new with the inefficient old systems if the minimum viable product (and hardware installation) takes more than 6 months to develop.
  3. Alternately, all programmers have experienced pure hacking environments where you inadvisable do software development on your production systems. We don't want to equate uncontrolled deployment processes with fulfillment of the "adequate incremental development" requirement.
  4. Similarly, we don't want to push all projects into a situation where they are neither required to do the big design up front waterfall lifecycle nor the "we sit in the same cube as the business owners" customer intimacy requirements that good agile guidance should include.

Instead, I would recommend a definition more akin to:
"Adequate Incremental Development - In general, delivery of a fully tested and releasable increment of software to the business owners every six months or less. Agency and Bureau CIOs should establish working definitions within their organizations that address the various types of development projects present within their environment and train their staff to ensure contracts meet those requirements."

I would also recommend removing or modifying element I1. If the only reason for reviewing all "cost estimates" is to satisfy the CIO's certification that they are "adequately implementing incremental development" requirement, we should defer to agencies to determine their best process for achieving that. Since every single tiny ODC purchase requires three separate cost estimates, I would much rather have the CIOs establish clear definitions, add standard contract provisions, train the key personnel and use some form of audit to meet that requirement rather than review 130 cost estimates every hour of the year. I would recommend an alternative to I1, but it appears G1 has already captured my thoughts on that.

No mention of enterprise architecture

FITARA, while providing the CIO with more power over the IT portfolio, does not mention or recommend the use of enterprise architecture (FEAFv2) as an essential component of the CIO's decision-making arsenal of tools, particularly utilizing the business architecture, in order to ensure business needs are prioritized in such a way to deliver value to the organization. Often times, CIOs become consumed by tactical needs of the infrastructure and solution architecture decisions and activities, while the business needs may not be as apparent without EA articulating the business alignment that is supported by the IT investments in the portfolio.

FITARA for Digital Ae

The OPM's newer guidance on CIOs are not enough for this ever changing world.

In reality, the future role of CIOs (including CXOs) must be aligned with the Silicon Valley's culture tied to INNOVATION and ACCOUNTABILITY.

In INNOVATION field - the emerging ole of software is becoming predominant, here the software will take the center stage (aka Core competency). This software in the driving seat will control hardware integration (not like Intel dominance days) as well as Internet of Everything (IoE) movements. This Innovation is fueled by software process improvement through automation (aka adopting to "DevOps" culture). At least after 75 years, the dream of Prof. Deming and Prof. Juran is becoming a reality.

In ACCOUNTABILITY field every CIO must be responsible for his/her own failure. As noted by every GAO reports, there was no accountability in the government compared to the commercial side.

Hopefully, the golden days of Acquisition (based on recent advances in Technology and Logistics) is coming in the government sector based on the new FITARA initiatives from the OPM.

Treasury OPE Comments on OMB FITARA Guidance

These comments focus on the portions of OMB’s guidance related directly to the CIO’s and CAO’s respective roles in the acquisition process as defined in the Common Baseline, as well as general acquisition guidance in Section E.

Section E Comments:

Section E, Paragraph 1: This paragraph references Attachment F. The guidance posted on GitHub does not contain Attachment F. Regarding IT Acquisition Cadres, Treasury feels it is vital for these cadres to include Contracting Officers (COs) and Contracting Officer Representatives (CORs), and that COs and CORs must be trained together, instead of training occurring in separate CO and COR tracks.

Section E, Paragraph 2: Will there be any oversight or tracking of agency contract actions that do not utilize FSSI vehicles? Without oversight or some reporting mechanism, it will be very difficult to identify which FSSI vehicles agencies aren’t using, and their rationale behind not using them.

Section E, Paragraph 3: Will the new GSA Software Category Management team replace, absorb, or work with DoD’s Enterprise Software Initiative (ESI) to reduce duplicative software license/maintenance contracts? OMB’s guidance states the Category Management Initiative will result in license agreements available for use by all executive agencies, however, DoD’s ESI has many contract vehicles civilian agencies are unable to utilize (e.g., Adobe, Microsoft, Red Hat). The software spend won’t truly be leveraged across government until DoD ESI and GSA ensure all vehicles awarded by either are available for all agencies to order against.

Attachment A Comments:
Paragraph K1: While Treasury agrees it is vital to have customer buy-in (up to and including the agency CIO for major acquisitions) on the acquisition strategy/plan, there is some concern that this usurps the contracting officer’s (CO) authority and/or has the potential to result in undue pressure being put on a contracting officer from an agency CIO in the event the agency CIO does not concur with the CO’s proposed acquisition strategy/plan.
Paragraph K2: Why is OMB requiring the CAO to notify the CIO when a planned acquisition includes IT? The agency CIO should institute policy to determine how IT-related requirements are identified and submitted to contracting.

Paragraph K2: “Substantial changes to the scope of a significant contract” is a very vague term. Recommend simply stating the language to simply state “CAO shall ensure no out of scope contract changes…” Also recommend defining the term “significant” contract.

FITARA:Section 831 conflicts with Independence section of HEA legislation

FITARA has seven separate sections (sections 831-837). Federal Student Aid’s (FSA) Performance-Based Organization (PBO) legislation and FITARA seem to have conflicting requirements with one of the seven sections (Section 831). Specifically, in FSA’s PBO legislation (i.e., the Higher Education Act), there is a clause (Section 141(b)(4)) about independence:

(4) Independence – Subject to paragraph (1), in carrying out its functions, the PBO shall exercise independent control of its budget allocations and expenditures, personnel decisions and processes, procurements, and other administrative and management functions.

The recently enacted Federal Information Technology Acquisition Reform Act (FITARA) has the following four clauses in Section 831 (Chief Information Officer Authority Enhancements) that seem to conflict with this clause and the general intention of the PBO legislation.

‘‘(i) That the Chief Information Officer of each covered agency other than the Department of Defense approve the information technology budget request of the covered agency,”

‘‘(ii) That the Chief Information Officer of each covered agency certify that information technology investments are adequately implementing incremental development, as defined in capital planning guidance issued by the Office of Management and Budget.

‘‘(C) REVIEW.—(i) IN GENERAL.—A covered agency other than the Department of Defense—
‘(I) may not enter into a contract or other agreement for information technology or information technology services, unless the contract or other agreement has been reviewed and approved by the Chief Information Officer of the agency;
‘(II) may not request the reprogramming of any funds made available for information technology programs, unless the request has been reviewed and approved by the Chief Information Officer of the agency;

‘‘(2) PERSONNEL-RELATED AUTHORITY.—Notwithstanding any other provision of law, for each covered agency other than the Department of Defense, the Chief Information Officer of the covered agency shall approve the appointment of any other employee with the title of Chief Information Officer, or who functions in the capacity of a Chief Information Officer, for any component organization within the covered agency.

Requiring the Department of Education’s CIO to approve FSA’s IT budget allocation and expenditures, IT personnel decisions, and IT procurements seems to be in direct conflict with the language and intent of FSA's PBO legislation. I believe there are strong arguments to support a determination that the FITARA guidance should be implemented in a manner that does not impact the independence and authority of FSA with regard to personnel, performance, procurement, and budget, as provided in the Higher Education Act, 20 U.S.C. § 1018(b)(4). I would welcome further coordinated discussions amongst PBOs (and similarly situated agency bureaus with independent authority of their management and procurement), their agencies, and OMB.

130 micro-purchase approvals per hour!

The average agency CIO would need to approve 130 charge card transactions every hour* to meet the review and approval requirements in sections I1 and K1. These micro-purchases average $309 per transaction. Similarly new ODCs that are purchased as part of an existing contract could similarly flood the IT executives in overwhelming minutiae. Your guidance should make it clear that approval authority for these charge card and ODC purchases on an approved contract, can be delegated down to far lower levels in the organization as long as they fall under a parent contract that has been approved by the CIO.

Improving Access to Commercial IT Security Standards, Best Practices, Innovations

FITARA goals cannot be achieved through policies and reporting alone. OMB must also address the barriers to commercial IT standards, best practices and innovations not visible to the traditional Federal IT Supplier base and FFRDCs. A 7 year root cause analysis of some 40 past studies and 30 major program failures revealed the hidden contributors to the primary causes that led to FITARA;

  • Antiquated waterfall acquisition processes developed and maintained by our FFRDCs
  • Flawed requirements and market research that obscures commercially available IT solutions that would provide lowest risk and life-cycle cost
  • Unfettered conflicts of interests by contractors working within the acquisition SDLC with a vested interests in outcomes
  • Lack of metrics for measuring both value and risk of implementation.

These challenges can be addressed with minimal effort by enforcing existing rules of law;

  • FAR Part 35 that restricts FFRDCs from competing with industry or developing material solutions
  • Clinger Cohen Act that requires streamlining of IT Acquisition Process, favoring COTS over GOTS and adoption of commercial best practices
  • Enforcing contractor OCI rules.

Federal Statistical Agency law and Executive Directives in conflict with FITARA

Comment from the Council of Professional Associations on Federal Statistics Regarding Proposed Guidelines for the Federal Information Technology Acquisition Reform Act

The Council of Professional Associations on Federal Statistics (COPAFS) represents over 300,000 individual researchers, educators, public health professionals, civic groups, and businesses that rely on the quality and accessibility of statistics that can only be effectively collected, managed, and curated by the federal government. COPAFS contends that the proposed guidance for the Federal Information Technology Acquisition Reform Act (FITARA) would violate federal law and Executive Directives that assure critically essential independence of officially designated statistical agencies and should thus explicitly exclude these agencies from its requirements. Potential consequences of less than independent collection, storage, announcement, dissemination, and selective accessibility to federal statistics include economic market disruption (related to agencies’ time-sensitive release of principle economic indicators), inadequate communication with those who answer surveys or use resultant data, and slow response to the need for on-the-minute statistical information for unanticipated federal policy or program decision making.

The Confidential Information Protection and Statistical Efficiency Act (CIPSEA; Pub.L. 107–347, 116 Stat. 2899, 44 U.S.C. § 101) provides strong confidentiality protections to many Federal agencies conducting statistical information collections such as surveys and censuses as well as other statistical activities including data analysis and modeling. Under CIPSEA, it is the statistical agencies themselves, not the Department within they reside, that hold ultimate responsibility and accountability for the confidential information that the agency acquires under a CIPSEA pledge. Any inappropriate use or disclosure of CIPSEA-protected information violates the law and can undermine public trust. The minimum standards for safeguarding confidential information under CIPSEA make clear that each person having access to confidential information understands the statistical uses that apply to his/her responsibility in maintaining the confidentiality of that information. In addition, these standards make clear that it is the statistical agency that is independently accountable for each part of the information protection process, including:
• determining and monitoring procedures for statistical collection and statistical release;
• evaluating the reason for accessing the information and controlling access to the information;
• maintaining physical and information systems security

We are particularly concerned that the proposed FITARA guidelines would prevent statistical agencies from guaranteeing the confidentiality of the data for which they are, by law, the stewards. As users of the data and selective data access procedures, we support statistical agencies’ independent monitoring, access and security and trust them to continue their outstanding job in doing so. Without the agencies’ guarantees, it would not be surprising to see survey response rates drop, with a consequential decrease in the accuracy of survey statistics.

Statistical Policy Directive #1 on “Fundamental Responsibilities of Federal Statistical Agencies and Recognized Statistical Units” (http://www.gpo.gov/fdsys/pkg/FR-2014-12-02/pdf/2014-28326.pdf) is more explicit about the actions and activities that must be independently controlled by the agencies without the influence of others, including the Secretaries of the Cabinet Departments in which they are organized. The Directive, issued under the authority of the Budget and Accounting Procedures Act of 1950 (31 U.S.C. 1104 (d)) and the Paperwork Reduction Act of 1995 (44 U.S.C. 3504 (e)), is aimed at maintaining trust in the accuracy, objectivity, and integrity of the Federal statistical system and its products. Lack of trust causes uncertainty about the validity of measures the Nation uses to monitor and assess its performance, progress, and needs by undermining the public’s confidence in the information released by the Government and/or reducing response rates to extents that affect quality. Even the perception of a lack of objectivity or a 30-second delay in the release of market-sensitive statistics can have substantial consequences.
Statistical Directive #1 specifies the responsibilities for which statistical agencies are held accountable. Under Responsibility #3, “Conduct objective statistical activities,” several requirements are notable with regard to the proposed FITARA guidelines:

• “Federal statistical agencies and recognized statistical units must function in an environment that is clearly separate and autonomous from the other administrative, regulatory, law enforcement, or policy making activities within their respective Departments.”
We interpret IT oversight as falling within administrative activities, meaning that it has to occur within the statistical agencies, not from outside.
• “Federal statistical agencies must be able to conduct statistical activities autonomously, (including)… when and how to store and disseminate their statistical products and which staff to select to join their agencies.”

The proposed FITARA guidelines would violate this requirement on several levels, including Departmental CIO approval of agencies’ selections for their own CIO, and their influence on decisions concerning statistical software and secure statistical data storage technology.

Furthermore, under Responsibility #4 “Protect the trust of information providers by ensuring the confidentiality and exclusive statistical use of their responses,” statistical agencies themselves, not their Departments, are responsible for maintaining strict privacy and confidentiality of statistical data. They are also independently responsible for assuring that the data are made available and utilized only for “statistical purposes,” as defined by law.
We are also concerned that the many approval processes required by the proposed FITARA guidelines could jeopardize the timeliness of federal statistics’ release, and the ability of statistical agencies’ “sworn agent” contractors to fulfill tasks central to the agencies’ missions.
Federal statistics are used: to allocate federal funding and services to states and local areas; as economic indicators directing private sector investment and location decisions; in gauging the state of economic development, education, trade, transportation, health and other functions of government; and to evaluate federal programs for evidence-based policy decision making. They must be accurate, objective, relevant, timely, and accessible to individuals cleared by the responsible statistical agencies solely for “statistical purposes” as defined by CIPSEA. CIO’s are a vital part of the support required to achieve this. But only the statistical agencies have the training and know-how to carry out the unique responsibilities given them by law and through Executive Directives.

Designated (by OMB) federal statistical agencies and currently recognized (by OMB) statistical units are: the Bureau of Economic Analysis, Bureau of Justice Statistics, Bureau of Labor Statistics, Bureau of Transportation Statistics, Census Bureau, Economic Research Service (USDA), Energy Information Administration, National Agricultural Statistics Service, National Center for Education Statistics, National Center for Health Statistics, National Center for Science and Engineering Statistics, Office of Research, Evaluation and Statistics (Social Security Administration), Statistics of Income Division (IRS), Microeconomic Surveys Unit (Federal Reserve Board), Center for Behavioral health Statistics and Quality, Substance Abuse and Mental Health Services (HHS), and the National Animal Health Monitoring System of the Animal and Plant Health Inspection Service (USDA).

Inspector General Independence

The Inspector General Act of 1978, as amended, contains a variety of statutory guarantees of Office of Inspector General (OIG) independence, designed to ensure the objectivity of OIG work and to safeguard against efforts to compromise that objectivity or hinder OIG operations. The feedback below relates to the issue of OIG independence for OMB's consideration.

First, we want to express appreciation for OMB’s inclusion of language recognizing OIG independence in the Scope and Applicability section. We recommend that any reference to the Inspector General Act refer to it as the “Inspector General Act of 1978, as amended.”

The guidance makes clear at the outset of Attachment A that “[a]ll references to ‘CIO’ refer to department/headquarters CIOs, and only references to ‘bureau CIO’ refer to the CIO or official-with-CIO duties within a bureau or any component organization of the agency.” We have some concern that the agency CIO would have the ability to control the appointment of the CIO of any component organization within the agency, including an OIG. We believe that such a requirement could impact the independence of the OIGs. See Section Attachment A - M1 (“The CIO shall be involved in the recruitment and shall approve the selection of any new bureau CIO (includes bureau leadership with CIO duties but not title …”).

We also wanted to highlight other provisions in Attachment A that appear to allow the agency CIO to have direct and significant authority of the IT functions of an OIG:

• C1: (“The CIO shall be included in the internal planning processes for how the agency uses IT resources to achieve its objectives. The CIO shall approve the IT components of any plans … This includes CIO involvement with planning for IT resources at all points in their lifecycle …”).
• D1: (“CIO reviews and approves major IT investment portion of budget request. Agency budget justification materials in their initial budget submission to OMB shall include a statement that affirms: the CIO has reviewed and approves the major IT investments portion of this budget request …”
• G1: (“The CIO defines the development processes, milestones, review gates, and the overall policies for all capital planning and project management and reporting for IT resources.”).
• J1: (“The CIO shall conduct TechStat reviews or use other applicable performance measurements to evaluate the use of the IT resources of the agency. The CIO may recommend to the agency head the modification, pause, or termination of any acquisition, investment, or activity that includes a significant IT component based on the CIO’s evaluation, within the terms of the relevant contracts and applicable regulations.”).
• K1: (“Agencies shall not approve an acquisition strategy or acquisition plan … or interagency agreement …. that includes IT without review and approval by the agency CIO.”).
• N1: (“The Chief Human Capital Officer and CIO shall jointly establish an agency-wide critical element (or elements) included in all bureau CIOs’ performance evaluations.”).

B. Chad Bungard
General Counsel
Office of the Special Inspector General for the Troubled Asset Relief Program

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.