6.1 Why Projects Fail
You will recall I have stated that digital transformation is not a technology project. So you may be asking why I have an entire chapter dedicated to projects.
In Chap. 1, I highlighted recent studies that indicated failure rates for digital transformation were as high as 84%. A failure rate this high signifies a multi-faceted problem. We have already discussed the need for a standard definition for digital transformation, the need to align organization leadership on the goals and objectives of digital transformation, the need for guidance and support at the board level, and the need for the appropriate governance processes and structure. Anyone of these, if not adequately addressed, could derail digital transformation efforts.
However, even if we accomplish all of these items, we still need the ability to execute. Ultimately, digital transformation efforts are executed as a series of projects. The projects could exist for a variety of reasons such as technology, business process, organizational structure, training, or communications. Understanding your organization’s natural tendencies and issues regarding projects is essential when undertaking an effort as complex as digital transformation.
We have all likely worked on a project that didn’t go the way we expected. It doesn’t have to be technology-related. It could be a home improvement project, a hobby project, a school project, or any other form of a project. When the project didn’t go right, did you analyze what didn’t work as expected or just accept it and move on?
Understanding why projects fail and how to prevent failure is the principal focus of this chapter. Now, before we go too far, I realize a multitude of books have been written on project management and how to execute successful projects. I am not going to try to emulate these books or prescribe a specific method to drive success. I am merely going to point out the most critical factors you need to consider when putting together complex transformational efforts and how to best position these efforts for success.
The building block for transformation efforts is the project. Projects, regardless of type, all possess the same three primary characteristics: scope, resource, and time.
In a perfect world, these are the only three variables we need to consider when planning a project. The scope defines the work to be done and the desired outcomes. Resources are the people and tools necessary to execute the project. Time is simply the time (usually a duration or a specified end date) we have to complete the project. A project plan is built factoring in each of these variables and is balanced. X amount of resources delivers the scope (desired outcome) within y amount of time.
Sounds simple, doesn’t it? Nonetheless, projects fail in companies at an alarming rate. The Planview 2017 Project and Portfolio Landscape report stated nearly 50% of survey respondents had a project fail in the prior 12 months (Planview, 2017).
According to the 2017 Pulse of the Professional report published by the Project Management Institute (PMI) project success rates were on the rise. Companies in this survey stated that 69% of projects in the past 12 months had successfully met their original business goals. This success rate was encouraging news, but a deeper dive into this excellent report showed only 57% of the projects were completed within their original budget and only 51% finished within their planned timelines. Further, the report broke the respondents down into groups on both ends of the project execution spectrum. Champions are described as those organizations completing 80% or more of their projects on time and on budget and achieving high benefits realization maturity. Champions comprised 7% of all survey respondents. The Underperformers are described as organizations with less than 60% of projects completed on time and on budget and had low benefit realization maturity. These organizations comprised 12% of all respondents (Project Management Institute (PMI), 2017).
The difference between the performances of Champions to Underperformers was dramatic. Champions completed projects on time 88% of the time versus 24% for Underperformers. Champions completed their projects on budget 90% of the time compared to just 25% for Underperformers. Most importantly, Champions met their original goals on 92% of projects compared to 33% of Underperformers (Project Management Institute (PMI), 2017).
There are many reasons behind the stark differences in project performance. We’ll cover a few of them in this chapter.
For now, let’s go back and use a simple example of a project you have likely done at home: putting together a piece of furniture described on the box as “some assembly required.”
With three daughters through college, I have had my share of sitting down with a box of components, a cryptic set of instructions, and a set of tools to build an assortment of desks, shelving units, entertainment centers, chairs, beds, and dressers.
I developed a process to do this. Get all the parts of the box, arrange them by type and place them around a central area where I am planning to work. I read the instructions to get the right tools in place and only then will I begin to work. I follow the instructions word-by-word and do not skip ahead. My brother observed this one time and commented, “I didn’t realize you were so anal about this stuff.” I prefer to take that as a compliment.
However, we have all seen the result when we don’t do this. We end up with gaps in components, drawers that won’t close, parts left over, busted knuckles, and a lot more time invested than we had planned.
Clear understanding of the end goal
Ownership and sponsorship
Skills and talent
Wrong solution, wrong partner, or both
Using our simple example of putting together a piece of furniture let’s examine some of the things that can go wrong.
You begin assembling the furniture without observing the picture on the instructions (or on the outside of the box). You don’t have a clear picture of what it will look like when completed. As a result, the pieces of the puzzle don’t make much sense to you, and you begin putting parts together that just don’t belong with one another. When you finally look at the picture, you realize your mistakes and have to disassemble and reassemble the furniture.
You read the instructions and realize it takes two people to assemble parts of the project. You don’t solicit any help, get to the part of the project requiring the assistance and have to stop until you can find another person.
The assembly of the furniture requires the use of specialty tools with which you are unfamiliar. As a result, you are using a power drill and over tighten a connection, stripping the screws and making completion of the assembly nearly impossible.
You work through the entire assembly process only to realize the table you assembled can’t support the weight of the TV you want to put on it.
These are examples of things that could go wrong with a simple home assembly project. In the worst case, a complete failure would cost you the purchase price of the furniture. More than likely if these errors occur you will work through them with a great sense of frustration costing yourself more time than you originally planned. Now imagine these same types of errors occurring on a sophisticated, multi-million dollar technology project.
Surely these basic errors don’t occur with corporate technology projects? Wrong! These are the most common problems plaguing business and technology projects alike. There are varying degrees of misses in each category, but make no mistake, almost all project failures stem from one of these four categories.
As luck (or perhaps lack of luck) would have it, I have experienced these issues at various times in my career. Each time a setback would occur my team and I would take the lessons to heart and work to improve our processes and approach to ensure we didn’t encounter the same problem again. Let’s cover four real-world examples of projects that didn’t go as planned (one for each of the categories). At the end of each example, I will tell you what we did to correct the issue and how we tried to prevent it from happening again.
6.2 Understanding Project Goals
Often, the most fundamental concept can prove to be the most elusive. Achieving a shared, firm understanding of an effort is a prerequisite for success. However, it is often elusive. At one of my previous companies, we were working on entering a new foreign market. It was unlike any market we had entered before, and we knew our existing systems would not function in the new country.
The challenge for this effort was all in finalizing the business model. In the beginning, we wanted to own the entire process and systems. We established an architecture model and prescreened many of the applications we thought might fit our business needs. The business then decided we would use a third-party partner and leverage all of their systems and processes. Our job shifted to simply integrating the solutions. A few months later, the negotiations with the partner fell through, and the vision turned to a secondary partner who had some, but not all of the systems needed. This new model required us to understand what systems we would need to bring to the table and how we would integrate those systems with the business partner. Then, two months into this process the business decided it would go back to the original plan and own all of the systems and processes. The catch to all of this back and forth on the model was that the end date for the solution never changed. In essence, the business spent over 10 months finalizing the fundamental model to follow and then looked to IT to find a way to make the dates.
In this instance, our IT group was able to deliver. Within five months we had stood up a very vanilla version of an ERP instance in a third-party data center in the new country. We had selected and integrated a new point of sale (POS) system to the ERP and established integration to a third-party logistics provider. To achieve this outcome, we had to streamline choices and keep options to an absolute minimum. We paid more than we had initially anticipated, but it was the only way to be operational in five months .
I recall a discussion with one of our senior executives who lamented the high cost. I quoted an old IT adage in a slightly different way. “We chose to spend 10 months debating the business model. The business model was foundational for entering the country. IT could not move forward with system work without a decision on the model. As a result, we had little flexibility regarding time. I also heard, repeatedly, from the business that we needed the solution to be of high quality and handle all of the issues we would be facing in the country. That left us with cost. We chose a single solution, a single integrator, and a single hosting provider. We just didn’t have the luxury of time to send the effort out for bid. In other words, we had chosen good and fast. We could not get cheap too.”
In this instance, our IT group sat down and discussed what we could have done to influence this effort to push the decision timeframe forward. In the end, we decided there was little we could do in this instance to change the decision cadence. We did determine we could use our new solution as the basis to build a more flexible/adaptable framework that could be applied to other countries when the time was right.
You will recall in Chap. 5 we discussed a major transformation project that spiraled out of control in terms of cost and time. The core issue in this effort was not technology. It was solidifying scope, agreeing on priorities, and committing resources (people and time) to the initiative elements that would bring the most value to the company. Scope creep was rampant in this effort, and much of it was not critical to delivering the core of the business case. As I was not there at the end, I am not sure what, if any, changes were made. However, I would hope the executives looked at their decision-making processes and ensured future decisions were tightly linked to the delivery of business value.
As these two stories illustrate, getting to a shared understanding of the problem or opportunity is not as easy as it might sound. We spent an entire chapter earlier talking about alignment and for good reason. Aligning all groups on a shared understanding of scope, priorities, and commitments is essential.
In the 2018 Retail Digital Adoption Survey, 53% of those organizations that had experienced issues with their deployment of various digital technologies cited “lack of complete or well understood requirements” as the root cause (Stone, 2018).
When an organization undertakes a significant transformation effort, all other projects and requests often suffer. Delaying or canceling non-critical projects is not a bad thing. However, often the groups not getting their requests serviced will become outspoken and work behind the scenes to obtain resources (people, money) to get what they want. This behavior is counterproductive and often results in “one-off” solutions that require significant rework later. These requests also distract business and IT from their priorities. It is for this reason alignment must be across all parts of the organization, even those areas not immediately impacted. Alignment is achieved by establishing the governance rules for transformation up front across the entire organization. The message from the CEO should state the transformation is the priority and all other efforts should be de-emphasized or delayed. The Program Management Office (PMO) or other governing bodies for the effort should reinforce this during status updates to the business.
6.3 Project Sponsorship and Ownership
The next story speaks to issues with ownership and sponsorship. Executives are often quite busy. Good executives have their finger on the pulse of their function and understand the importance of changes to their supporting processes and technology. These executives must be visible and outspoken in their support of any effort. Lacking executive support is often a recipe for lack of focus and attention from project participants.
Executives should also have a finger on the pulse of their talent. As the executive will likely not be on a project day-to-day, they need to be thoughtful about whom they appoint to represent them. The right person should be highly knowledgeable of the business function, empowered to make decisions for the project, pragmatic in their decision-making (they understand what is needed and just as importantly, what is not needed), and accessible.
We had undertaken a significant program to implement new technology and processes to support the lifecycle of private brand sourcing. The technology had been proven in a few other retailers, though none quite as large as our company. We put together a project team, and the business appointed a director to the effort to run the day-to-day activities. Project status reports showed all aspects (scope management, time, and budget) on the project on-track throughout much of the design and development phases. In fact, the effort stayed on track until we entered user acceptance testing. We sent a team to our foreign buying office to walk through the new screens and processes. As most of the technology targeted the foreign buying office, we wanted to get their buy-in and ensure they received adequate training before moving forward. To our surprise, the associates in the foreign buying office were not acutely aware of the project. When they started going through the screens, it became very apparent the new technology-enabled processes were going to add many hours (perhaps days) to the process of establishing new vendors in our system.
When our team returned, we assembled and reviewed what they had found. In essence, the initial screens had over 100 data elements to be entered to set up a new vendor, with the majority (of the elements) configured as “required.” The executive sponsor and I were both shocked. The entire focus of the project was to streamline the existing processes while adding a degree of rigor to ensure the correct information was available to all parties. It became readily apparent the first goal (streamlining) had been pushed aside in favor of a very rigid set of system-enforced rules that added significant time to all processes.
As we unearthed more details, it became apparent we had two issues on our hands. The director from the business assigned to the project was not as knowledgeable on the business processes as had been thought initially. Worse, he had not communicated with the foreign buying office to get their inputs. Thus, the business sign-off on the design of the system was virtually useless. The other big issue was the IT program manager. The IT program manager was aware the end users had not reviewed the design in detail. The program manager chose not to disclose the issues in their status reports, as they didn’t want to “call out” the business leader and move the project to an unfavorable status.
As a result, we missed the original due date by over 8 months. The first phase of the project exceeded initial cost estimates by more than 40%, and the subsequent phases of the project were canceled resulting in a loss of a good portion of the business benefit.
From the IT standpoint, we took action on the program manager and spent a substantial amount of time reiterating to our program leadership team that it was their specific responsibility to bring all issues to the surface. The business, surprisingly, left the director on the project but augmented with a vice president level to help push the effort over the finish line. In our post-mortem process, we uncovered many other items that could have alerted us earlier to the trajectory of the project and allowed us to course correct. These were communicated across the program management team and added to our quality review process.
As we discussed earlier, the right level of sponsorship and the right talent to oversee an effort is vitally important. Having the right talent is especially vital for decision-making roles on the project team. While all participants should work effectively together as a team, there must be checks-and-balances in the project governance structure to promote and support the unearthing of issues. Also, project roles and responsibilities must be clearly defined. If the project team understands what is needed and their role in delivering it, you have a significantly better chance of success.
6.4 The Right Project Talent
Of course, when we establish project roles and responsibilities, we have to find a way to fill them with the right talent. While that may sound simple, the most common problem plaguing projects is talent. Specifically, we are talking about the lack of available talent to ensure successful delivery of the project. Talent issues pop up in a variety of ways. Mostly it boils down to a simple question. Do we have people with the right skills, in the right quantities, available at the right time to do the job needed?
While this may sound basic, it is surprising how many organizations take on technology demand without understanding if they have sufficient resources to fulfill the demand. In the Planview Project and Portfolio Management Landscape report for 2017, 73% of survey respondents reported they don’t have enough resources to meet incoming demand (Planview, 2017). Wow! The business expects the work to be performed, but there is not sufficient capacity to do the work. Not being able to meet expectations is any easy recipe for disappointing the business.
Let’s return to the premise of the simple resource question. There are three essential parts to the question. First, you must establish if you have all the skills needed to deliver a project. While we immediately jump to questioning the availability of technical skills, this can also mean such items as a business process, leadership, and organizational change management. Without the right skills on the team, the other two parts of the question are moot.
If we establish we have the right skills, the next part of the question is do we have them in the quantities needed to satisfy project demands. This capacity question pertains to all groups, including those outside of IT, that will be working on the project. For example, we have three experts in the business process we will be modifying on the project. We need at least one full-time person to do the job. In this instance, we would say we are covered (at least for now). What if we needed five experts to do the job? In that case, we don’t do the project; or we find ways to add additional capacity (augmentation).
Finally, we talk about timing. In other words, do we have the right skills, in the right quantities, available at the right time? Accounting for these factors is where the talent equation often breaks down. We may have the first two parts of the question covered (skill and number), but at the moment of execution, we struggle to get our resources focused on the tasks needed to deliver. Lack of availability and focus may be because the resources are working on more pressing items, poor planning, or attrition. However, the result is often the same. The project misses dates, the timeline is elongated, and costs begin to increase.
I have observed various IT functions spread their resources like peanut butter across projects. Highly sought after technical experts may be assigned to eight to ten projects at once. Each project is vying for a fraction of the expert’s time to meet their project timelines. Assume the expert was superhuman and could establish the focus needed to deliver on all ten projects. If just one of the projects missed a deadline or had a poor estimate, it would potentially have an adverse cascading effect across all of the other projects vying for the expert’s time.
I have observed project plans built on the assumption of 45 hours per week for critical resources for over a year. What happens if someone is sick? What happens if they decide to take a vacation? Do we expect the key resources will not participate in other functions like team or organization meetings?
It is vital to have dedicated technical and business resources to work on critical, highly prioritized efforts. This is especially true of efforts such as digital transformation. Leaders should compile a critical resource list before beginning digital transformation work. These leaders should then be held accountable for freeing the critical resources time to participate at the appropriate level.
We have an entire chapter (Chap. 8) devoted to talent so I won’t delve too deeply into the subject here. However, as I scanned my brain for stories to illustrate the problem of talent, I came upon the realization I could choose almost any project I had observed suffering and find an element of talent issues at play.
Beginning a project without understanding and accounting for the skills needed to be successful.
Not having the right skills and personal attributes at crucial execution roles such as project manager
Not having a dedicated business sponsor or technology sponsor
Not understanding the talent dependencies with other projects running at the same time
Trying to run a project with “part-time” resources in critical roles
Over-reliance on external contractors
The first bullet is one I see quite often in companies without a means to understand their project demands and resource capacity. I relate this to “flying blind” for organizations. You commit to an effort without understanding if you have the resources needed to execute. In the same vein, I have seen companies commit to projects knowing they had a resource deficiency and assumed they would “figure it out” when the time comes. The problem with that approach is frequently specialty skills may require going outside the organization for help. These searches may take longer than expected and delay critical parts of the project. Companies must have an idea of their talent sourcing plans before undertaking significant projects.
Project management is often a thankless job. Quite often project issues are attributed to project managers, but upon inspection, we find the project manager was never set up to be successful. A true project manager needs to be skilled in project management disciplines including risk management, issue management, task management, estimation, project quality, change control, and resource management. They need to be appropriately empowered to provide unfettered status reports to project sponsor(s). They must also have the right personal behavior characteristics to succeed including communication skills, leadership, organization, collaboration, and be courageous in their decision-making. The larger and more complex the effort the more vital it is to have the right people leading.
The importance of project sponsorship can often be overlooked. We assume a “group” or “committee” can oversee an effort and it isn’t necessary to put a single person in charge. Not having an involved leader is the best recipe I know for scope creep, delays in decision-making, and inconsistent execution. I recall a significant (greater than $40 M US) project delivered on time and under budget. While many of the other large projects in the portfolio suffered from delays, this project was executed crisply and the resulting deployment was flawless. The difference? The business sponsor was top notch. She had a deep understanding of what scope was needed to achieve the business case. Just as important, she had a keen understanding of what was not needed and used this knowledge to keep the team focused. She devoted the majority of her time to the effort and it paid off in a big way.
Frequently we put together excellent plans for a project only to find out that one of our essential resources has been pulled into another effort at the same time. Accounting for other project dependencies, especially those sharing critical resources, is a must. Building contingency plans upfront based on these dependencies can help head-off potential issues that delay or stop a project dead in its tracks.
Honestly, in my career, I have witnessed project plans with more than 50 people assigned, none giving more than 25% of their time. You might ask, “how could this happen?” “How” can be explained by understanding the IT demand versus capacity problem. The business is screaming for a project to start. IT tries to appease the business by starting the project even though there are no available resources. IT project planners will “steal” enough time from various projects and operations efforts to get the new project started.
Does this work? No. Projects will always have some form of part-time resources. However, there needs to be a core of resources you can count on to be there to drive execution. Without that core, projects tend to drift and often never make it to implementation.
Just as there will be part-time resources, in the majority of cases you will need external resources. These resources may provide expertise that doesn’t exist inside the organization in sufficient quantities to execute the project. The resources could be required to provide additional, short-term, capacity to push through a project. While these are valid reasons use of external resources should always be done in context, with an eye towards production cutover. For example, if we bring in an expert to help with a new technology, it is incumbent for IT to allocate resources to work with the expert to learn. Otherwise, IT will be unable to support the technology when the external expert leaves. Finally, staffing a project with heavy concentrations of external resources can rob the project of tribal knowledge that is so important in ensuring a solution meets the needs of the business.
As mentioned before, we will cover the talent equation in more depth in Chap. 8. However, being mindful of these five issues will help ensure a smooth start to your transformational efforts.
6.5 The Right Partner and Right Solution
The final category of project issue we will cover is selecting the wrong product or the wrong partner. When I think about this particular issue, I can’t help but recall an old joke.
A salesperson met his untimely demise and was given a choice between Heaven and Hell. He attended a tour of both places before making his choice. He toured Heaven first. It was very peaceful and serene. Angels were playing harps and conversing in their flowing robes. While quite nice, the salesman wanted to see Hell as well. He was shocked when his tour of Hell was amazing. Everyone was partying and having a great time in Hell’s various nightclubs.
When asked for his decision, he replied: “While Heaven was very nice, Hell seems more like how I would like to spend the rest of my eternity. So I choose Hell.”
After making his decision, the salesman descending into Hell. He was cast into a pit of fire, chained to the wall, and tortured. He screamed: “Wait a minute when I did my tour, Hell was nothing like this! Where are all the parties and nightclubs?” To which one of Satan’s followers replied: “Oh, that was just the sales demo.”
Like the joke, I have observed dozens of technical solution demos that looked great but had nothing of substance behind them. In many cases IT was asked to evaluate a product based on a “great demo” given to a business executive or team. Often, our IT team uncovered the same issue, the demo was great, but the solution would not work for the problem we were trying to solve.
Choosing the right solution or right partner is more than a single demo or even multiple demos. It is about the appropriate amount of due diligence from the right people inside an organization. Due diligence should include line-of-business functional experts, technology experts, and procurement experts. Even when you do all of this, things can happen that you didn’t foresee. Critical resources can leave your selected partner, a new software release from a vendor could be plagued with defects, or a complex business requirement doesn’t function in the manner needed.
None of these issues has to result in project failure. However, not addressing these issues quickly with likely cause disruption to any project. Selecting the right solution and partner is a critical element to mitigate project impacts.
During the “honeymoon” stage when you are envisioning what the new solution will provide you, everything is rosy. All solutions/partners look good during this stage. The question is will your partner go the extra mile when things get tough. Rest assured, on transformational efforts, things WILL get tough.
A common problem I have seen in selecting a software provider or integration partner is what is often called the “halo effect.” It goes something like this: “We had success with this solution or vendor; therefore, all other efforts will be successful as well.” This is a dangerous assumption. Incumbent solutions and providers deserve an opportunity for new business, but it should not be an absolute given that they will win. Eliminating bias is difficult, but it is required to get the right answer.
Conversely, there is the “Pitchfork effect.” It goes something like this: “We tried them for xyz project five years ago, and it didn’t work. Don’t waste your time.” Changes occur in technology at an accelerated pace. Ruling out a provider over a past failure could mean you are eliminating the best solution without ever giving it a chance. At the very least, re-examine the reasons why the previous attempt didn’t work and determine if there has been sufficient change to warrant another look.
Finally, remember that “square pegs fit best in square holes.” In other words, a solution built in a specific manner, for a specific purpose, doesn’t always flex or extend into additional business use cases. Assuming a purpose-built solution can be easily extended is a common mistake I have observed many times in the past. It can be something as simple as a vendor has a long list of successful implementations using database provider X. You don’t use database X, you use database Y. You challenge the vendor to migrate their solution to database Y. The vendor agrees, and then you are shocked when the solution has numerous issues due to the vendor’s lack of familiarity with database Y.
By now hopefully we have established that (a) choosing the correct partner and the correct product/solution is critical, (b) eliminating bias (positive and negative) is vital to ensure you make the right selection, and (c) don’t force a solution or partner into unfamiliar territory unless you are willing to sign up for all the associated risks.
I can recall a few times we violated the above tenants, and paid the price. One such story illustrates the importance of a number of these points. We had implemented a software solution to manage task workflow from the corporate office to our stores. The solution was from a smaller vendor and we implemented it under time and under budget. In case you were wondering, that (under time and under budget) does happen from time-to-time. The solution worked well, and the business was thrilled with it.
A few months later the company decided it wanted to extend task management to third-party vendors doing services in our stores. The business and IT quickly agreed the existing solution could be extended to handle the new scope of work.
While it seemed logical the existing solution could be extended to handle vendors the scope quickly began to escalate. Within 6 months, the “extension” was beginning to look nothing like the previous solution. Three missed deadlines later and nearly 2× the original cost, the system went into production. The system had its share of issues and stabilization took nearly three more months. As we conducted our post-mortem, we found numerous incidents where scope was added unnecessarily as minor changes in the business process would have nullified the need for a system change. In the end, we had a true one-off system that the vendor struggled to maintain for years until it was ultimately retired. In other words, it was a “lose-lose” proposition for both the vendor and our company.
Clearly, our IT team made some mistakes on this project. We quickly anointed the vendor without fully understanding the scope. We didn’t have the right sponsorship or leadership from the IT side to stop unneeded changes. The vendor, being small, was ill prepared to build what amounted to a “custom” solution and struggled to meet deadlines.
One other story represents the danger of taking a solution down the wrong path. Our company was beginning to open stores in Canada. Many of our retail systems were developed in-house, so we were forced to create Canadian versions of these solutions. Our company leveraged an actual cost solution for managing inventory. We were one of only a handful (at most) of retailers in the country using such a costing method. As we looked at our options for Canada, our CFO decided we should try a different approach for Canada. Instead of rebuilding the systems we had in the US to operate with different currencies we would use a third party application and modify our business processes to work with the new application.
As the Canadian project progressed, we were pleasantly surprised at how we were able to seamlessly migrate the custom developed applications to Canadian constructs. However, red flags begin to emerge on the new inventory costing solution. Our business unit in the US was also handling Canada inventory costing. They decided they did not want to use two different processes, as it would cost them too much time. They began processing massive change requests to effectively make the new packaged application operate in the manner they were accustomed. I called the result “Frankenstein.” The new system and associated integrations were overly complicated and left us with a solution that would prove to be an absolute nightmare to upgrade. The project exceeded its original budget by several million dollars and missed multiple deadlines.
In this case, we did our due diligence and selected a reasonable solution based on a mutually agreed upon scope. However, as the project progressed change requests completely altered the scope. Unfortunately, the business sponsor approved the changes, and it led us down a terrible path. In other words, we tied to make a square peg fit into a round hole. We would have been much better served to have just migrated our existing systems.
After this, we strengthened our policy on software package selection to try to curtail future “Frankensteins.” We explicitly stated any software package, to be considered for deployment, must provide at least 90% of core functionality. We expressly noted the CIO and Project Sponsor must approve all customizations. Finally, we entirely excluded all customizations that directly accessed package databases (requiring a level of data extrapolation).
6.6 Positioning for Transformation Execution
As our stories illustrate, lots of things can go wrong with projects. Now imagine the challenge inherent in a large enterprise transformation. These large-scale transformations are not for the faint of heart. In order to be successful, organizations must be very thoughtful and deliberate in their direction, as frequent changes in direction will quickly derail efforts. They need strong leadership and sponsorship to make the tough decisions necessary to keep the effort on track. They need to ensure they select the right solutions and the right partners to build their “envisioned future.” Most importantly, they must have the right skills available, at the right time, and in the right quantities to meet the demands of the project(s).
Checking all of these boxes is daunting, even for smaller projects. Adding the elements of shrinking business cycles, accelerated technology adoption cycles, and an extremely competitive landscape for top talent and it may seem impossible.
Needless to say, it is not impossible. However, we can’t approach these types of efforts in the same manner we approached projects in the past. To be successful, IT must change, the business must change, and our expectations of our partners must evolve.
As we discussed in Chap. 2, it is best to think about digital transformation in terms of building a platform versus executing a single project. Whereas a project has a definitive start and stop, platforms are built with extensibility in mind. Now, before I go any further on this topic, projects are still the building blocks for establishing a platform. However, the projects to create a platform are often tighter in scope and time duration. Managing scope through short cycle project execution is reflective of the evolving nature of the platform. Large and long-running projects need to be avoided as they negate much of the flexibility of a platform.
A platform offers easy integration and “plug-in” points for new capabilities. In fact, a platform encourages external groups (partners, customers) to use it. The mark of a good platform strategy is one that reduces the complexity (or “friction”) between an organization and its consumers. In simple terms, a platform makes it easier for people to do business with an organization.
A single project or program does not build a platform. Platforms evolve. While platforms clearly begin with an end-state in mind, their inherent extensibility allows the end-state to morph as business conditions dictate.
Deaf Diagnostic
Attempting to operate an initiative as complicated and comprehensive as digital transformation in traditional manners will marginalize opportunities for success. Old approaches and methods will struggle to adapt to the level of speed and agility needed to transform successfully.
This diagnostic underlies the importance of change in digital transformation. Challenging the status quo, even on project execution processes is critical to success. As one of my favorite sayings goes “the definition of insanity is doing the same thing over and over again and expecting a different outcome.” Change is incumbent to win in the digital age. The next two chapters cover the types of changes needed in more detail. We will begin with the structure and process changes required and wrap up with a chapter on talent.