The previous blog, The 4 Envelopes: Transparent Project Management, began defining the first of the four envelopes that must be pushed to implement a new paradigm in federal IT by highlighting how the current implementation and presentation of project status fails to either inform or enlighten the stakeholder public. In this post, I’ll describe why the envelope must be pushed and how it can be done, laying the foundation for next week’s part 3 that describes how it could look.
Why Push It?
There are several very good reasons why we have to push the Program and Project Management envelope:
- Restore public confidence in the ability of the federal government to actually make successful IT investments by making even modest projects completely transparent to critics and supporters alike,
- Engage the public much earlier in the life cycle, when changes have the least impact and cost,
- Engage subject matter experts much more broadly and earlier in the life cycle, where they can contribute the most to investments, and finally
- Eliminate the opportunity (and temptation) to spin, shade, or obscure project ground truth from public, congressional, and special interest oversight.
Lets take those reasons one-by-one before we dig further into who we could actually accomplish them.
Restore Public Confidence
Whether we believe in bigger or smaller government, we at least ought to have confidence that what the government does do actually works. Yet Gallup finds that only 34% are somewhat or very satisfied with how well it works as of early January, 2016. Moreover, we believe that over 51 cents of every dollar of tax money spent is wasted and 73% of us say the private sector is more efficient than the government.
Not only has public lack of confidence in federal civil servants set a new high of 33% having little or no confidence, only 35% of those same federal civil servants are now confident or very confident in the ability of their own department or agency to protect information systems from cyber intrusions (down 30% in only two years). Clearly, public confidence in federal technology is at record lows in the wake of serial IT disasters like healthcare.gov and OPM’s failure to protect tens of millions of security records.
While putting out the IT disaster fires may be the first step (already undertaken by the U.S. Digital Service), I take the position the next step in restoring public confidence must be putting in place the processes that prevent such disasters in the first place. To make sure the public is completely informed and up-to-date on our IT investments (and that they are not leading to yet another disaster) they must exhibit completely transparent program and project management: we’ll know it when we see it, and not until we see it, at whatever level of detail we choose. We’ve been fooled by inaccurate dashboards before and under-informed by updates to the still unreliable dashboard visible today – only real time, project ground-truth can rebuild confidence.
Engage Stakeholders Earlier
Section 13.3 of the Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK) is crystal clear on the importance of engaging stakeholders earlier rather than later:
The ability of stakeholders to influence the project is typically highest during the initial stages and gets progressively lower as the project progresses. (loc. 7212, Kindle Ed.)
What would healthcare.gov have been like if, from the very beginning and throughout the entire development of the site, complete detail and transparency to the public would have been made available? To be sure, many (if not most) wouldn’t have used the information. But those that did might have had a good chance to detect the flaws that accumulated into the failed launch. At the very least, we wouldn’t have believed the “all green” indicators on the federal IT dashboard for the project right up until it went over the cliff!
Granted, it would have taken more than just transparent project management to have averted the cliff – it would have taken the other three envelopes that are the subjects of this blog series too. But that notwithstanding, traditional project management artifacts, schedules, resources, and earned value metrics would have raised so many flags early on that we would never have gotten close to (much less gone over) the cliff of failure.
Enlist Subject Matter Experts
All of the four envelopes we’ll be discussing have their own community of subject matter experts. Program and project management may be near to top of the list when it comes to certified expertise, with the Project Management Institute (PMI) driving standards and certification nationally and vying for worldwide leadership with the Association for Project Management (APM), a transparent project management site for each federal IT project would attract considerable process expertise in addition to the subject area experts (e.g., healthcare, labor, commerce, etc.).
PMBOK continues by pointing out that, unlike the current federal IT dashboard, this must be a two-way process:
The project manager is responsible for engaging and managing the various stakeholders in a project and may call upon the project sponsor to assist as needed. Active management of stakeholder involvement decreases the risk of the project failing to meet its goals and objectives. (Loc. 7212, Kindle Ed.)
Section 13.3.1.1 of PMBOK continues:
The stakeholder management plan provides guidance on how the various stakeholders can be best involved in the project. The stakeholder management plan describes the methods and technologies used for stakeholder communication. (Ibid.)
In practical terms, this approach calls for the implementation of a Stakeholder Relationship Management (SRM) implementation – a specialized version of typical CRM implementations. Categorization of stakeholders as well as moderation of responses will certainly impose much higher communications resource costs but, compared to the cost of failure, costs that will carry definable value.
Eliminate Opacity
I can’t emphasize this last reason strongly enough, having borne witness to its insidious effects. The PMI Code of Ethics & Professional Conduct lays out both mandatory and aspirational conduct for project managers. All PMI members and PMI-certified project management professionals are obliged to adhere to them. Among the section 5.3 Honesty mandatory conduct is section 5.3.1:
We do not engage in or condone behavior that is designed to deceive others, including but not limited to, making misleading or false statements, stating half-truths, providing information out of context or withholding information that, if known, would render our statements as misleading or incomplete.
Only the lack of opacity can eliminate the potential contextual and withholding pitfalls that intentional “spinning” and factual omission that inexorably lead to violation of the ethics and professional conduct code. The stakeholder management and communications plans are roadmaps for how and to whom such communications are made and managed – not blueprints for self-defense or blaming others at the expense of the full truth.
How to Push the Envelope
The federal government cannot effectively push the IT portfolio, program, and project management envelope without first establishing a Project Management Office. That’s right, there is no government-wide PMO providing either guidance or operational management of the most important IT investments being made by the federal government. Even the job descriptions for IT Program Manager and IT Project Manager are created and maintained by the Office of Personnel Management as part of the Acquisition Workforce. If you look at the standard for all federal IT positions, don’t expect to find any references to academic preparation or qualifications – there aren’t any, despite our national academic leadership in computer sciences and information technology.
Despite the addition of IT Program Manager and IT Project Manager job titles in 2009 and 2011, almost all federal departments and agencies are still using the unauthorized (and non-standard) sub-title appended to the original IT Specialist job title (e.g., IT Specialist [Project Manager] even though specifically precluded).
The only way to effectively and efficiently establish such an office is to do so within the Executive Office of the President, in the Office of Management and Budget’s E-Government Office, with a Deputy CIO reporting directly to the federal CIO. This would mimic how the U.S. Digital Service was created and staffed and could be done by executive order. Beginning with the functions of an Executive PMO, the office could immediately begin to have standardization impact across all major investments requiring OMB-300 reporting. The office could also coordinate PortfolioStat reviews as a function of PMO oversight. As staffing fills out, the operational functions of a PMO could be initiated as described below for “strategic” investments, with staffing detailed from the relevant departments and agencies.
Scale Through Systems
The existing federal IT dashboard is only a façade that puts a user experience over manually reported, XML transmitted “data.” To enable a consistent reporting of major and strategic (see below) projects and a cost-efficient, government-wide Project Management Information System, the federal CIO’s E-Government office should follow the guidance of PMI’s Standard for Program Management and Standard for Portfolio Management by using PM information systems to achieve both ubiquity and scale. That’s not to say it should be one large, monolithic PMIS that could easily become a single point of failure, but an integrated set of interoperable systems with common definitions and interfaces implemented.
Depth Through Drill-down
Unlike the current dashboard, where only the business cases can be drilled-down into, the real-time, integrated PMIS described above would support public access to any level within the entire investment portfolio with particular emphasis on in-depth information for development, modernization, and enhancement (DME) investments. While those investments currently comprise only 23% of the federal $86 billion annual budget, it’s where the cost-drivers for subsequent operations and management portion of the life cycle where 69% of the annual budget gets spent.
Focus Through Categorization
Federal IT investments are generally categorized as either major or non-major. The criteria used is decidedly department or agency-specific, however, and doesn’t clearly define inter-departmental systems. As we learned with healthcare.gov, a major, policy-based system requiring multiple departments and agencies to participate transcend the “major” categorization and demand a higher degree of both management and oversight. To that end, a new category of “strategic” should be created and managed directly by the federal CIO’s E-Gov office, adding operational PMO responsibilities to the currently non-existent executive PMO functions discussed above.
Bottom line: If an IT investment is critical to the administration successfully achieving a major policy objective, the investment needs Executive Office of the President management and oversight. Simply having a “lead” department is insufficient to drive interdepartmental cooperation and interoperability.
Follow the Leader
From the perspective of a project management professional and IT executive from the private sector, the absence of a PMO within the federal CIO’s office is mystifying: what part of following the leadership of the private sector from the last twenty years has the federal government missed? And why just project management? Multiple departments have already jumped on-board the Chief Data Officer movement blooming widely within the private sector, but very few have implemented (must less effectively implemented) PMO’s to manage their investments and portfolios. I argue it’s the lack of Executive branch leadership in IT portfolio, program, and project management. It’s something that can be simply solved just as the IT first-responders of the U.S. Digital Service were quickly created in response to the result of lacking a federal PMO – and it is the only thing that will prevent more IT fiascos that USDS will eventually have to fix.
Next week, I’ll conclude the Project Management Envelope discussion by describing how a federal PMO might look, both organizationally and the related, updated, IT dashboard perspectives.
Leave a Reply
You must be logged in to post a comment.