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
As a continuation of our blog series on system selection, it’s time to discuss helpful tips to facilitate a successful product demonstration. The organization and management of the entire process requires upfront preparation. If you drive the process, your demo evaluations will be far more effective.
Demonstrations are one of the most critical components of the software selection process. Seeing a system in action can be a great learning experience. But not all demos are created equal. Let’s talk about how you can level the playing field. To make the most of everyone’s time, CC Pace recommends the following best practices for product evaluations.
Tip One – Keep your process manageable by evaluating no more than five systems. If you evaluate too many vendors, it becomes difficult to drill down deep enough into each offering. You will inevitably suffer from memory loss and start asking questions like, “which system was it that had that cool fee functionality that would be really helpful?”
Tip Two – For each software vendor, set a well thought out date and time for the on-site demo. Depending on your team’s travel schedule, try to space out the demos a few days apart so that you have time to prepare and properly analyze between sessions.
Tip Three – Logistics play a big role in understanding how a system looks and functions, so do your part to help your vendors present well. Whenever possible, arrange for a high-quality projector or large HD screen for the attendees in the room. Hard-wired internet connections are always better. There’s nothing worse than being told, “the screen issues are because of a resolution problem” or “it’s running slow because the air card only has one bar.” Providing these two items can easily remove doubts about external factors causing appearance and performance issues.
Tip Four – Involve the right people from your organization. It’s important to have executive sponsorship as well as hands-on managers involved to assess the software modules. This is also the best opportunity to get “buy-in” from all parts of your organization.
Tip Five – Be sure to head into these demonstrations knowing your key requirements. Visualize it as a day in the life of a loan and follow a natural progression from initial lead into funding. Jumping around causes confusion and can be difficult on the vendor.
Build a list of requirements based on the bulk of your business. Asking to see how the software handles the most complicated scenarios can send the demo down needless paths. No one wants to watch a sales person jump through a bunch of unnecessary hoops for a low-volume loan product.
If you highlight which functional capabilities are most important to your organization, the vendors can spend more time demonstrating those capabilities in their software. Communicate how you think their software can help. But be careful not to justify why something is done a certain way today, but rather focus on how it should be done in the future.
Tip Six – The easiest way to take control of the demo process is to draft demo scripts for your vendors. Start by identifying the ‘must-have’ processes that the software should automate. Don’t worry about seeing everything during this demo. Set the expectation that if the demo goes well, the vendor will likely be called back again for a deeper dive. Provide a brief description of each process and send it to the vendor participants so they can show how their software automates each process. The best vendor partners will have innovative ways to automate your processes, so give them a chance to show their approach.
As you watch the demos, keep track of how many screens are navigated to accomplish a specific task. The fewer clicks and screens, the better. Third-party integrations can significantly help with the data collection and approval process. Always have an open mind regarding different ways to accomplish tasks and don’t expect your new software to look or act just like your legacy system.
Simple scorecards should be completed immediately following each demonstration. This will make it easier to remember what you liked and disliked and prove invaluable when comparing all the systems side-by-side when your demos are complete.
One final suggestion: always request copies of the presentations. Not only will this help you remember what each system offers, it’s useful when the time comes to create presentations for senior management.