Success Factors for Large Programs

As mission priorities, technology, governance, and other factors have evolved over the years, so have what we believe are the most critical success factors in the acquisition and delivery of large-scale programs in the federal government.

So what are these factors? Here’s a hint: it’s not about the technology.  Although the technical solution can still have a significant impact on cost and other factors, it is rarely the difference between success and failure.  This was not always the case - as technology and the Internet were maturing, it was easy to “get in trouble” with a poor technology solution.  In the sections that follow, we will describe this evolution in technology, and identify what we believe to be the three truly critical factors for long-term program success.

Technology: Important but not as Critical
Not so many years ago, the technology solution for a large government IT program could be a make-or-break decision.  A review of past government IT programs shows that many of these initiatives struggled, from a purely technical standpoint, in three key areas: (1) usability (can users get their job done effectively?); (2) interoperability (can the systems interact with other, related systems?); and, (3) scalability (will the system perform when we load it up with lots of end users, now and in the future?).  Often, government was forced to address these issues through custom development efforts, or large-scale customization efforts for commercial products.

Not surprisingly, an enormous amount of industry R&D has gone into addressing these issues.  First and foremost, the maturation of the Internet has made each of these objectives significantly easier and more cost-effective to achieve. This ubiquitous infrastructure (which barely existed 10 years ago) has allowed the product vendors to focus on their own capabilities, rather than re-inventing ways to enable integration, or to revamp the user interface.

Consider the ERP packages, which at their core are enormous, standardized platforms that are designed from the ground up to enable both scalability and interoperability.  In fact, the ERP’s have made so much progress that they are now also adding government-unique business functions to their core platforms.  Add to this picture a wide array of middleware products (which also did not exist 10 years ago), which are entirely focused on scalable and cost-effective integration.  The end result is a technology landscape that is drastically different than 10 years ago, and significantly changed from just 4 or 5 years ago.  Put another way – if there were 100 ways to screw up a technical solution just 5 or 10 years ago, today (in a relative sense) there are probably less than 20.  The bottom line — technology is not the make-or-break determining factor in today’s government IT programs.

But don’t just take our word for it — we would also encourage readers to review the numerous GAO and IG reports of the past several years that describe “what went wrong” with enterprise system implementations across the federal government.  To our knowledge, not one of these reports says that a root cause problem was that “…the government selected the wrong product.”  In the vast majority of these cases, the problems encountered related to issues of acquisition strategy, governance, requirements management, and other people- and process-related topics.  So in this context as well, the message is clear - it’s not about the software.

In the sections that follow, we will describe what we believe to be the three most critical success factors in system acquisition and implementation for today’s federal government environment.  And, following this discussion, we will provide some practical considerations and recommendations for how to use this information.

1. Linking Acquisition & Delivery Strategy
Clearly, the federal government has focused enormous talent and resources on the development of policy, process, and management approaches for the acquisition of large, complex systems.  As technology has matured, however, we believe that additional issues within the acquisition process should come to the forefront. These include:

Building a link between acquisition and delivery. One of the toughest jobs for the government in designing an acquisition strategy is in anticipating how industry will react.  As programs become more complex, it is even more critical that an industry perspective is brought to the table early on.  The challenge, of course, is finding industry ‘veterans’ that are willing to conflict themselves (and their business) out of the implementation phase.  Few consultants in this field have actually served as a Capture Manager on a large industry bid; even fewer have won these bids and gone on to serve as an industry Program Manager during delivery.  For many years, industry has been hiring government executives to provide them with key insights and thinking from the government’s perspective; it’s time that government did more of the same.  It is not an exaggeration to say that even the smallest change to a seemingly insignificant item in an RFP can have enormous impact on industry responses, and more importantly, on the subsequent implementation itself.

In addition to the perspective and insight that this role can bring to acquisition planning, there is the potential to ‘bridge the gap’ between the acquisition phase and the implementation phase.  Passing a signed contract to the Program Manager is clearly insufficient; instead, what if a ‘trusted advisor’ from the acquisition phase was able to transition into implementation, and bring this knowledge and expertise with them?  Clearly, no one from the System Integrator (SI) ecosystem is able to play this role, due to conflicts of interest (OCI).  We believe that this ‘gap’ remains a significant area of risk for future programs.

Clearly defining the strategic objectives. There are a wide range of ‘strategic objectives’ for large IT programs (some usually more ‘strategic’ than others…).  These objectives need to be prioritized and well understood in terms of their implications, and the potential relationships and conflicts between them.  For instance, objectives that address the end user work force and user efficiency can often be at odds with objectives that relate to interoperability and integration.  Why?  We have found that users often have to do more work to ‘make integration happen’ — often to include the entry of data that they didn’t previously collect.  The end result is often good for the system as a whole, but requires that the end user carries a larger part of the burden.  This is exacerbated when ‘ease of use’ or ‘user efficiencies’ are bandied about up front as strategic objectives for the program.  Leadership must be clear from the outset as to the end objectives, their prioritization, and the relationships between them.

Note that a ‘perfect’ acquisition strategy does not guarantee success – but a fundamentally flawed one can almost certainly spell failure.  Going forward, we believe that these ‘root-cause’ flaws will most often arise when the long-term consequences of a particular acquisition strategy, objective, or approach are not fully understood.

2.  Stakeholder Alignment
Every large-scale enterprise software deployment, in one way or another, has attempted to address the issues of stakeholder commitment and alignment to program requirements and objectives.  So why does this continue to be such a challenge?  And, why do we consider this a critical factor for success?  We see several issues:

First, stakeholder alignment programs as proposed and delivered by the systems integrator rarely work. There is too much conflict of interest, lack of trust (though often unspoken) across the PMO-Customer-SI spectrum, and most importantly, these programs can’t start until the integrator is selected, under contract, and underway.  By then, it’s often too late.

Key stakeholders need to be engaged during the acquisition strategy phase, and then throughout program implementation. So many times, key stakeholders are in a ‘block’ mode with new programs before the contract is even awarded.  Even worse, sometimes the PM doesn’t even know it. Stakeholder alignment efforts need to be more programmatic in nature, beginning during program formulation and continuing after contract award. In fact, the program to engage stakeholders cannot be dependent on the selection of any particular product, integrator, or solution.  Large, complex programs require true experts in understanding root cause drivers of individual and organizational behavior, coming from a combination of expertise in psychology, organizational systems, business consulting, and management.

This kind of stakeholder engagement and alignment should not be confused with the more traditional ‘change management’ programs offered as part of the implementation plan.  Although these programs also have their purpose, a programmatic approach to stakeholder alignment can actually reduce the cost and effort necessary for the change management program.  (For instance, the change management program does not need as exhaustive and expensive a communications and marketing campaign if all of the key stakeholders are aligned and committed to the program strategy from the outset.)

The power and leverage of fully committed and aligned program stakeholders cannot be overstated.  There are few better investments (from a cost-benefit standpoint), when done right and up front – and not as ‘damage control’ after the fact.

3. Outcome-Based Program Management
It is not an enormous revelation that effective Program Management is a critical factor in the ability to deliver on a program’s vision.  And, performance-based or outcome-based approaches are not new.  Our point here is that the program management function for the next generation of large-scale programs must be much more than ‘cost and schedule’ focused.  It should be integrated with the key stakeholder and acquisition strategy activities – and probably operate on a level where a ‘balanced scorecard’ type approach would enable thinking across much broader dimensions than is typically the case.

What does this really mean in terms of program execution?  For instance:

Requirements Management. Most large programs struggle with the complexities and conflict inherent in the requirements management process.  The good news is that some aspects of this task are becoming easier, as technical solutions (out of the box) meet a larger percentage of the overall requirements, and as the Internet, middleware, common architectures, and other factors continue to reduce customizations and technical complexity.  Now, the ‘people and process’ aspects of requirements management can come to the forefront, particularly as ‘joint’ programs attempt to meet requirements across diverse organizations.  What we need (in terms of requirements) will still be very important, but we believe that success will be achieved through an increased focus on how.

Imagine a program management approach that gets beyond a largely cost and schedule-based focus, and brings critical insights to issues of prioritization and implementation based on the views, objectives, and measures of success across key stakeholders and their common vision and strategy.

The transition from a data-rich to a knowledge-rich environment.  Over the past 10+ years, a large number of enterprise-wide systems have been implemented across the federal government.  Unfortunately, relatively few have moved beyond the ability to provide basic reporting, and into a mode where the information is available to key stakeholders in a fashion that enables improved management decision-making.  We believe strongly that there is enormous potential today to mine the data of these systems and significantly improve our effectiveness in program management, and in understanding root cause drivers for future success.

Even the lack of data has value.  There is a huge amount of deployed functionality today that is not being used by end users – for all kinds of reasons.  An analysis of this gap would undoubtedly uncover all sorts of ‘low hanging fruit’ for efficiencies and improved program outcomes through relatively low-cost solutions such as targeted training, SOP updates, communication programs, or other means.
This potential also applies to ‘institutional data.’  What if we had a storehouse of lessons learned for all of the ERP implementations in the federal government for the past 10+ years?  If the collection and transition of this ‘data’ into ‘knowledge’ saved even one future program, the cost of data collection would have paid for itself many, many times over.

We do understand, of course, that all of this is much easier said than done.  A balanced-scorecard style, outcome-based approach to program management requires an ability to quantify things like the quality of leadership, team effectiveness, and customer satisfaction, as opposed to more easily measured things like cost, delivery dates, system deficiencies, or function points.  Successful program managers will find ways to better understand these ‘qualitative’ measures, and to apply rigor and resources where necessary, just as they have when analyzing budgets and schedules.

Summary and Implications
Without question, technical analysis and product evaluations are still important; however, other factors have become much more important to the long-term success of large government programs.  In particular, we strongly recommend that new and/or recently launched programs consider the following early initiatives and objectives:

• Ensuring that the acquisition strategy planning and development effort is done with a thorough understanding of how that strategy will impact technology options, industry bids, and implementation risks.  Key relationships and potential conflicts between strategic objectives should also be identified;

• Launch of a programmatic effort to build commitment and alignment across key program stakeholders, and to understand the influencing factors and root cause drivers that may impact opinions, behavior, and eventual program execution;

• Development of an integrated and outcomes-based program management approach that takes the above two factors into account, manages results through balanced-scorecard style performance metrics and data, and can adapt over time as the requirements and stakeholders change.

The eventual success of these programs no longer hinges on the selection of the right or even ‘best’ technical option; the government must recognize this and devote talent and resources to the program areas and factors that are high risk in today’s environment. 

Back to top		read previous newletter

© 2007 Suntiva LLC. All rights reserved.