Gambling on Project Execution
A startling statistic that often gets overlooked is that 70% of projects world-wide fail. Each year, more than one trillion dollars are lost to failed projects. Most importantly, statistics show that these failures are frequently not the result of a lack of technical, hardware or software capabilities. Instead, these failures are typically due to a lack of adequate attention being paid to program management.
After seventeen years working in program management―implementing enterprise business strategies and technology solutions―I continue to be surprised by business leaders who misunderstand the differences between project management and program management, or simply think them to be two terms that refer to the same thing. Fact is, program management and project management are distinct but complementary disciplines, each equally important to ensuring the success of any large-scale initiative.
Let’s take just a minute to level-set the roles of both. Project management is responsible for managing the delivery of a ‘singular’ project, one that has defined start and end dates and is accompanied by a schedule with a pre-defined set of tasks that must be completed to ensure successful delivery. Project management is focused on ‘output’. Program management, on the other hand, takes a more holistic approach to leading and coordinating a ‘group’ of related projects to ensure successful business alignment and organizational end-to-end execution. A program doesn’t always have start and end dates, a pre-defined schedule or tasks to define delivery. Program management is primarily responsible for driving specific ‘outcomes’, such as ensuring the targeted ROI of an initiative is achieved. Put another way, program management is basically the ‘insurance policy’ of a project, the discipline needed to make sure all the right things are done to ensure the likelihood of success.
One analogy I often use to help differentiate the roles of a program manager and project manager is that of a restaurant. The executive chef (project manager) works within a defined budget, makes certain the kitchen is adequality staffed and creates the menu. The executive chef will provide defined tasks, processes, tools and strategies that ensure efficient and consistent delivery of meals. The meals are a tangible delivery (output). Overseeing the chef, the restaurant owner (program manager) will provide the executive chef with a budget to work from and will closely monitor the output of the kitchen. The owner will make sure each delivery and support role is adequately staffed, trained and paid (e.g., wait staff, hostess desk, dishwasher, bussers and bartender). The owner will also make certain all the details like music and lighting are in place and establish an appropriate ambiance. The owner will make sure the right tools are in place for flawless execution (such as utensils, glasses, napkins, water pitchers, pens and computers), while making sure expected standards and key performance indicators are being met to achieve overall profitability targets and a great end-to-end customer experience (outcomes). The restaurant owner’s primary responsibility is to focus on merging the tangibles with the intangibles to support successful business strategy execution.
When it comes to mortgage banking, an industry that’s known more than its fair share of failed implementations, it is critical that we start giving program management a greater priority, and ensuring that those commissioned to perform the role are equipped with the requisite skills and tools. Whether it’s adding a new imaging platform, bolting on new CRM or POS technology, or something as expansive as replacing an LOS, every enterprise initiative requires a project manager to be leading the implementation effort and a program manager focused on change management and roll-out. Consider the addition of an end-to-end imaging system. A program manager’s tool box should include strategies and frameworks to effectively manage the roadmap for each critical impact point. This would include things like training, updating policies and procedures, executing an internal change management strategy, synchronizing marketing communications, and updating key performance indicators. In some instances, the project may require staff analysis, skills assessments, compensation analysis and adjustments, or even right-sizing of the organization. All of these are key components of the program manager’s toolbox, and not generally covered within the role of a project manager.
Bringing this dialog back full-circle, program management helps reduce project failure rates by maintaining a holistic approach to guiding an organization’s successful adoption of the impending change, leaving the nuts and bolts of build-out in the hands of project management. By addressing the myriad of intangibles required to orchestrate successful adoption and acceptance of change by an organization’s personnel, program management also helps ensure that business strategies and projects remain in full alignment and ROI objectives are achievable. Preparing management and staff for the impending changes defuses fears that can send adoption off the rails and eases the transitions and realignment of resources and roles that often accompany larger initiatives.
In closing, it’s not surprising to find the lines between project and program management will easily get blurred. Our experience is that it is often difficult to identify a really good project manager that is proven capable of undertaking a large-scale effort, but even more so to find someone truly adept at managing all the moving parts of the program. This difficulty is even more apparent in organizations where undertaking significant projects is a relatively rare occurrence and these skills are simply not found among existing staff. While it may seem adequate to budget for a singular project manager and hope that the program elements will be attended, managed and executed, unfortunately, “hope” is not a viable strategy when it comes to business-critical initiatives. The assignment of a skilled program manager, whether sourced internally or externally, will ultimately prove to serve as an effective insurance policy to your project investment. In an industry where failure cannot be afforded, it’s time to stop gambling on project execution and begin implementing program management
Pulling from our considerable experience with the unique aspects of implementing a mortgage loan origination system (LOS), CC Pace has recently published a new white paper on the topic, “The Art of Planning an LOS Implementation Budget.” The information covered in the white paper, while essentially specific to LOS implementations, is broadly applicable for any product implementation project.
Best practices indicate that thorough project planning is the most critical step for a successful system implementation, and we concur wholeheartedly. One of the key activities that should be performed during the planning phase is the development of a detailed implementation budget. The budget is particularly important when establishing expectations with Senior Management and gaining support for the effort. Too often, planners fail to consider the costs beyond those of the software, vendor configuration and any vendor-provided customizations when in fact the all-in cost of an implementation includes much more.
We hope that readers see the importance of taking a more comprehensive perspective when planning their next project and we welcome your feedback. What other line items do you include in your budget preparation process?
Is the RFP dead? As a tool for helping guide the selection of the best possible loan origination software, the traditional Request for Proposal seems to be increasingly viewed as an optional, and not particularly helpful, part of the selection process these days. And for good reason.
We at CC Pace have been questioning the value of a formal RFP for LOS selection, at least as typically applied, for some time now. Traditionally, the RFP is used to serve two primary functions: 1) to provide an apples-to-apples comparison of features and functionality among a group of worthy competing systems and vendors, and 2) to provide helpful documentation to the selection decision. But in today’s origination software market, the functionality included with competitive systems is more alike than ever before. LOSs have matured such that the differentiating factors are most often “how” they do things, not “what” they do. The RFP is simply not well suited to “how” distinctions, as “yes or no” questions are geared more for “what” and seldom shed light on the more nuanced distinctions of the candidate systems. In short, why bother asking detailed functionality questions when what is really needed is a better understanding of how each system handles those features that are “make-or-break” factors in your search?
The big problem for many lenders trying to navigate the software selection process is getting too caught up on debating the merits of a plethora of “bells and whistles,” while largely ignoring the bigger questions of whether the system meets their most important criteria and can they be successful in implementing it? In most situations there are only a relatively small number of things that really define what is absolutely critical, so why not limit the RFP to a short list of things you want the vendors to provide detailed answers on? Beyond that, well-orchestrated, in-depth system demonstrations typically do a better job of telling you whether a given system will meet your functional needs in a way that will fit well with your company’s organizational culture and processes.
Once having used detailed demonstrations to narrow the field to a small number of seemingly suitable candidate systems, the most important things a lender should want to focus on are 1) which of the systems can be successfully deployed in my shop and 2) will we be happy with the results afterwards? As simple as they may seem, these questions are exactly what you should strive to figure out in the process of selecting a system. And surprisingly they are often left out of the selection process entirely.
Too often lenders try to answer the first question (can we successfully deploy the system?) by looking at who the vendor has sold the system to recently. Many attempt to shorten the selection cycle simply by accepting that if Company ABC and XYZ bought the system, it must be good, without regard as to whether ABC or XYZ have successfully deployed it as yet, or if they’ve even begun that process. The truth is that not every LOS implementation goes all that smoothly, with something like a quarter of them failing outright. Rather than asking the vendor about their track record for successful implementation, it is far better to speak to as many customers of that vendor as possible and ask them directly. Probe into how their implementation efforts went, how happy were they with the vendor through that process, what kind of attention they received, and whether everything went as planned. Most of your lending brethren will be remarkably candid about this process when asked, even if the response doesn’t reflect all that well on them or the vendor. Use that candor to your advantage and learn from it.
Then ask how similar ABC and the others are to your company. When it comes to an LOS, one size does not fit all, so success with one company may not mean that much if they aren’t very similar to your company. Do they have the same operational model, offer the same products, and leverage the same channels? Ask them what level of effort was required of their own resources and how well prepared they were to meet those demands. Make sure you are ready to hold up your end of the implementation bargain, so listen carefully to what those that have succeeded tell you. Don’t over-reach by choosing a system that demands in-house analytical, configuration or development skills that you aren’t well-suited to provide, as those are critical factors when assessing suitability of organizational fit and common contributors to implementation struggles.
When it comes to being happy with the resulting system post-deployment, once again we strongly suggest doing your homework by talking to the vendors’ customers. Speak to as many current clients of the system as possible and ask probing questions about their satisfaction. Be honest with them about your expectations and goals and solicit their feedback on whether the system, in their opinion, can deliver. Here again the real trick is to not set yourself up to fail. Take the time to document your expectations up front, then carefully vet whether the system under consideration is truly aligned with those expectations.
The goals you are trying to achieve by replacing an existing LOS should be your north star guiding the process from start to finish. The desired outcomes should be things far more substantial than just successfully implementing a system. Clearly defining those desired outcomes at the outset is critical to guiding the implementation process, and to measuring your success at completion. Focusing the selection process on how to meet your critical needs while increasing the likelihood of successful deployment and roll-out is the right approach and one that relies very little on the traditional RFP.
So, should the RFP be laid to rest? My vote would be “no.” The RFP can provide important value, but skip the lengthy laundry list of functionality check boxes. Keep it short, ask open ended questions and focus on those critical things that are the real “make or break” factors in your search. But more importantly, the RFP should only be the start of your due diligence, used to help narrow the field before launching into asking the really big questions of whether you can succeed and by happy with your choice.
Still a bit overwhelmed with the selection process? Let’s talk.