Portfolio Management

I've recently been given a good reason to consider the Portfolio Management (PfM) component of Defense Business Transformation (DBT). A number of briefing requests coming from interested Flag officers - both from the recent past and in the near future - have led me into many discussions about this subject. What surprises me about some of these discussions is that several people, who are considered pretty smart about Business Transformation, have not readily seen the connection between the suite of DBT tools and PfM.

There are several components of Business Transformation that lend themselves to PfM in the Defense Department, but they are only effective when they are used together. If the DBT program is implemented in a piece meal fashion (i.e. investment review without architecture compliance, or architecture compliance without connection to a transition plan, or any of the above not connected to an annual review), the result is a lot of extra paperwork without much effect. I've seen at least one implementation like this that started off with all the Transformation tools together, but the program was fragmented over time. Soon after, the individual pieces turned into check-the-box exercises - with no one really understanding why.

When working together, each of the tools of Transformation amplify and enhance one another. Think of them as serious bolt-on enhancements to the Capital Planning and Investment Control (CPIC) process. An investment review, for example, that is informed by a careful scrub of both the solution architecture (the series of diagrams and supporting materials that describe the potential solution to a problem) and the Enterprise Architecture (the series of diagrams and supporting materials that describe the overall enterprise) will reveal to the investment review board where there are overlaps between investments, where standards are being met (or not met), the extent to which an investment aligns with leadership priorities that are described in the Enterprise Architecture, and where some operational activities (sometimes activities deemed critical by leadership) are unsupported or ignored.

Doing all of this kind of analysis often creates additional burden (usually unfunded) on program offices if, for example, Enterprise standards are not being met by the initial design. Without an Enterprise Architecture Compliance plan (required by law in cases where investments are not compliant with the Enterprise Architecture), leaders would be in an uncomfortable position of either allowing an investment to go on as planned and ignore the Enterprise Standards or kill a potentially good investment for the sake of preserving a standard. Neither course of action is optimal.

With an Enterprise Architecture Compliance Plan, necessary modification can be identified during the investment review and then deferred via the plan until they are appropriately planned and budgeted for. Investments are monitored not less than every twelve months via the Annual Review requirement. If proper documentation is maintained and the Annual Review is coupled with the Plan and EA compliance, each investment can be moved by controlled and manageable degrees to compliance with standards that create transparency, interoperability, etc.

A scrub of the solutions architecture against the Enterprise Architecture also reveals where there are overlaps, duplication, or differences in implementation of the same capability. Where these overlaps, duplications or differences are found, the investment review boards are empowered to bring programs together to work out their differences. The results of these program meetings can be expressed in both the EA compliance plan and in the Enterprise or Component Transition Plan as appropriate.

I've heard a good argument that the Investment Review associated with the Defense Business Transformation program occurs too late in the life cycle of a new capability. The law says that anyone spending money to modernize, enhance or develop an business IT system must obtain obligation authority before obligating funds. So... people do what they usually do. They put "get obligation authority" on the checklist somewhere near the end of the list of things to do, then wait until the last possible moment to start the process.

One of the reasons for this is because the government doesn't always know what it's actually going to do - with enough detail to pass a review board. There is so many options to chose from and so many ways to implement any modernization that the details of that modernization are not done until the contract is cut and contractors are put to work. Sometimes, the contractors themselves figure out what the implementation is going to look like - AFTER the contract was awarded.

The law forcing due diligence, EA compliance, and EA compliance planning before obligation authority is granted, really cramps those who come to the table unprepared. Paperwork becomes a mad dash and a "just tell me what to submit" exercise instead of a thoughtful portfolio management application. The law makes no apology for this. The DoD should take this as a sign to start the process earlier.

If implemented correctly, supported by technology, and embraced by leadership, Defense Business Transformation can be one of the greatest (possibly the only) PfM tool available to the entire Department and backed by the law. All it takes is a few creative and energetic people to pull it all together. The raw materials are there for the asking.