The term ‘disruptive technology’ refers to inventions or improvements on current technologies that change how consumers, businesses, or an entire industry operates. These technologies can be introduced by established companies or startups. And it is crucial to use project management strategies that have been tested over time.
We have gained some experience in this regard with our core technology, the LzLabs Software Defined Mainframe® or simply SDM. The SDM is a positive disruptor in the realm of legacy mainframe applications. It provides a compatible environment for running applications built for legacy operating environments and software languages, thus allowing organisations running mainframes the opportunity to modernise their core legacy applications on a modern platform. Previously, despite an almost universal desire to liberate mainframe applications to improve interoperability and business agility whilst reducing legacy IT costs, the risk and complexity of rewriting or recompiling code have been assessed as too high by many before the option of the SDM came along.
Five key principles
Tim Cook said that “people like things they can do now, not just think about.” Not surprisingly, the success of disruptive products and services has largely depended on how the leaders in these companies managed delivery projects.
At LzLabs we believe that complete and sudden change is not a necessary result of disruptive technology. That’s why we champion an incremental, step-by-step migration and modernisation approach. Our delivery model and philosophy take inspiration from five key principles.
1. Don’t fall into the perfection trap
When rolling out a product with the potential to shift an entire industry, it is pretty easy to be tempted to delay things to make them perfect and check every single item. In a project for a retail organisation, we tried to aim for perfection. and explored the possibility of pushing a new version of our source code manager, LzWorkbench, to allow them to manage a new engineering team with specific code management requirements. In the quest to ensure we had captured every possible order scenario, we ran dangerously close to the code freeze dates and had to focus on delivering the scenarios required 98% of the time, which proved to be more than adequate.
Pursuing perfection for perfection’s sake will usually lead to procrastination amongst the team, which can affect the overall success of the project. And it goes without saying that project leaders need to set strict deadlines within which the team have to achieve various milestones.
2. Reduce the fear of the unknown
A meeting is often considered successful and productive when the project team members share updates, ideas and progress and action points are agreed upon. But super-structured and efficient meetings may become a hideout for the elephant in the room: the fear of the unknown, or those things no one wants to talk about.
Everything needs to be shared with complete transparency to reduce the fear of the unknown. In a recent rollout, the client’s project team had overlooked informing some end-users of the upcoming changes to the functionality due to the training effort anticipated and the subsequent negative reaction predicted to ensue. Our LzLabs team pushed for a town hall meeting and, interestingly, the team that had not been fully briefed were extremely happy in the end. They had been bogged down by some labour-intensive tasks which the old process required. But the new process was found to be much simpler even if it did require more training investment to start.
Team members shouldn’t always have all the answers or make an extraordinary effort to find them. This may sound counterintuitive, but the reality is that giving the team the chance to brainstorm solutions for the challenges being faced in the different areas of the project can be the source for some of the best solutions needed to successfully build a disruptive product or technology in line with clients’ needs.
3. Set the expectations for the scope early
When delivering a new disruptive technology, you won’t have the luxury of including everything you want before shipping the product to the real world. So, the scope of the project needs to be agreed upon to avoid wasting time on non-core issues. The scope should be created while considering the time and budget.
The process to define and arrive at a minimum viable product (MVP) is the most important thing to get right. There needs to be some buy-in from the clients to understand that they might not get everything they will like from the get-go. For example, with one of our earlier releases for a financial institution, they had to decide if they would trade the performance of some of the batch jobs for a new useful feature which could only be enabled by disabling the performance booster. They decided to defer the update as the performance in their industry was the most important priority—and they went live without the new feature until the next release which removed the booster dependency. The goal is to decide early on decide what ‘good enough’ looks like and stick to the decision, knowing that quick improvements and iterations build an MVP that can be shipped to the market for early adopters to use.
4. Build a resilient and creative team
When creating a disruptive product or technology, you will encounter some challenges that may seem impossible to overcome. Having a resilient team that believes in turning impossibilities into possibilities is crucial in such times. A good number of the things you will do when implementing disruptive products have never been done before. Building a resilient team also involves listening and taking care of the psychological needs of the group.
You will need a team that is ready to think outside the box if you want to do things differently from everyone else in the industry you are trying to disrupt. Building resilience will require project managers and other leaders to give their teams the freedom to fail. The creation of disruptive products usually involves building several prototypes that may never ship to the market.
5. Develop a framework for idea evaluation
When building a disruptive product, many ideas will be brought to the table, and project managers must decide which ones to implement. However, it is important to build a framework for determining the best ideas that will take the project a step further. This framework should include minimum requirements that any idea should meet before being considered.
Some of the requirements that can be considered may include the impact of the idea on the project’s progress, the risk of implementing it, the effect on customer value, the resources (financial and human) required, and the time it will take to implement the idea. Having this kind of framework makes it easier to choose the best ideas to implement in the project without wasting resources.
It is also important to involve the entire team when creating this framework. When members understand the framework, it becomes easier to know why some of their ideas were not implemented in the first place. Team members can also use this framework to screen their own ideas before sharing them in meetings.
But even with all the strategies, there are still serious challenges disruptive companies face. Let’s look at three of the most common ones.
Putting together the right team
To push a delivery forward you must have a team willing and able to see the bigger picture. New technology means new ways of thinking and you need the right team to keep the delivery on track. This may sound obvious but it can represent a big hurdle for projects that call for skills which become increasingly scarce. Most disruptive tech is cutting-edge and there is a scramble to up-skill the current target users and adapt fast to keep up with the change needs of a project of that kind. Take PostgreSQL, for example. By some estimates, it is the fourth most popular database in the world, and yet expertise can be hard to come by in the wider market as most talents are snapped up by the engineering teams of bigger PostgreSQL users.
The race to beat time
If you want to implement a good idea, you must move before you lose momentum and support. Any delays in shipping the MVP or making the first iterations could reduce the chances of successfully delivering your disruptive technology to the mainstream market. In the early days of today’s social platforms, product teams were required to create and release new features almost daily.
Knowing when to pivot
This brings us to the last point of knowing when to pivot. Something that will potentially shake up the industry will need several iterations before arriving at the core offering. The point of change from the original direction to where the clients need to go is a delicate dance—and the team must be prepared to provide the value that clients expect. Deciding when to pivot should largely depend on the feedback from the early adopters. The leaders of any organisation that prides itself as agile need to be ready to change some of their original beliefs if the early adopters don’t find them helpful. Tech leaders can find it hard to rapidly change the product based on feedback because it goes against their initial beliefs about the technology or product. Delivering disruptive technology requires using the ideas pipeline to know what works and acting on it quickly to deliver customer value. Recently the LzLabs team have understood, based on the feedback from our client base, that operational services and solutions could be offered to the client to support their onsite team with the rollout post go-live, thus softening the cutover effect and ensuring best practices are implemented and followed for optimum success.
It always seems impossible until it is done. And we can find solace in the words of system scientist Peter Senge: “People don’t resist change; they resist being changed.” Because that gives us the perfect reason to keep delivery management as simple as possible.
