Why technology transformation fails
Why do technology transformations fail? This is a question I’ve been asked throughout my career. To answer the question, you first need to define failure. As a seasoned higher education operator, I like to point back to the business case as the make-or-break assessment of a technology transformation’s success.
So, let’s ask the question again, but with more clarity: why do technology transformations fail to meet their business case expectations? Or, put differently, how can you make sure your technology transformations meet or exceed expectations? The answer is in our name. Metavasi is Greek for transition, and we chose that name for a reason. We believe the key to unlocking value from technology lies in the process of transition activities.
The word transition alone is important to understand. Transition’s most common definition is the movement, passage, or change from one position, state, stage, subject, or concept to another. This is why we refer to technology projects as technology transformations. Through your transition from your current state to your future state, you will realize a transformation. But how do you get there? You can find plenty of resources around things like software development strategies, project management, and process improvement, but to us, success requires the alignment of the software development lifecycle (SDLC) with what we’ve termed the process change lifecycle (PCLC). With this in mind, we are introducing our latest framework at Metavasi Partners - the Institutional Technology Transformation Framework.
At Metavasi Partners, we wanted to share a different approach to solving the challenges institutions face with technology transformation - a holistic approach to technology transformation that demonstrates the interconnections between process and technology throughout the lifecycle of a technology project.
If you have ever been involved in a technology project, you have likely heard variations of some or all of these:
● The business changed the scope, added requirements, isn’t willing to change, wants to customize everything…
● The technology team doesn’t have enough resources, doesn’t have the right skill sets, never said that was going to be a problem, just wants to meet their timeline…
These statements are often made because the software development lifecycle is not in lock step with the process change lifecycle. Our framework addresses this problem head on by aligning the two cycles. More than a project management or process improvement approach, this framework provides the blueprint for technology transformation in a practical, step-by-step approach, beginning with aligning on the value proposition.
All too often business case development is completely skipped, or just a check the box exercise while the true driver of the change is an executive leader’s perceived problem and solution - why are we spending so much time/money on this? What if we could do this? Great starting questions, but you must keep drilling down further and understand how the technology is going to solve the root cause of that perceived problem and more importantly, what it takes to get there. To do this, we recommend four simple steps:
1) Identify the problem - what is it you are trying to solve?
2) Recommend several solutions - buy vs. build vs. do nothing
3) Decide on a path
4) Develop an ROI - the assumptions placed in the ROI model will be leveraged throughout the rest of your project and will be the guard rails for scope creep/degradation and defining what success looks like in your future-state
Once your value proposition is understood, technology transformation travels along two, interconnected paths across your functional and technical teams. We already mentioned the technology sector leverages lots of methodologies to describe the software development cycle. We stuck to the high-level stages that are most common, but feel free to adapt and adjust to what your institution uses. For our framework, we break down the technology track into: analysis, design, development, testing, deployment, and maintenance. At Metavasi Partners, we believe the secret sauce lies in the corresponding stages for the functional teams: requirements, decisions, process redesign, transition readiness, go live, and continuous improvement.
Take note of the verbs that sit between the technical and functional stages: clarify/define, collaborate, build, prepare, triage, and monitor/assess. For those of us who need a little more detail and substance to a framework, we have added in the primary activities to complete for each stage in both the functional and technical tracks. We will touch on some of these in future posts, but for now we are providing this framework to the higher education community to create awareness of the interconnectedness of functional and technical teams that enables successful, sustainable technology transformation at institutions.
Was this helpful? Are you in the midst of a technology transformation at your institution? Are you thinking about purchasing a new technology to improve operational effectiveness or the student experience? We would love to hear from you. To contact us, just fill out our request form or call us at 866.439.8399. Also, be sure to like our LinkedIn page so you don’t miss out on future posts.
