ROI. Return On Investment. This concept exists in just about every facet of life as we know it. You might consider ROI when playing the stock market. You might consider ROI when purchasing a musical instrument, or an automobile. Even when choosing ingredients with which to prepare your favorite meal, ROI plays a role in decisions you might make every day. So it should come as no surprise that ROI is a major success marker for the rollout of development workbench software.
Those of us who are fortunate enough to work in industries and at businesses that allow us the privilege of coding on a z/OS platform know that, at this point in time, we do not lack choice in which development workbench we choose or are provided with to get our work done. My choice? IBM Developer for z Systems (IDz). I have been working with IDz for many years now, and if were to be given opportunities to go back and do it all again, I would choose IDz time and time again. So you would assume that since I have been working with IDz for so long, I would be an expert and know every in and out, every view and perspective, all tools available in the workbench and how to leverage every piece of functionality contained within.
Believe it or not, I don’t.
In my line of work, I touch 35-40% of the functionality that is included out-of-the-box with IDz. That’s a fairly liberal estimate as well. So why not push for more usage? ROI. I have determined that this level of usage meets my ROI at this point in my career. That usage level marker may change, but we’ll discuss that in a moment. Let’s dig in to how I determined my ROI and how you can apply that thinking to your own workbench implementation.
I am a tools educator by title. I run enablement sessions for IBM tools, with my specialization being on IDz education for the ISPF developer. With that in mind, I have specific curricula that I teach based on the tools that I am running sessions on. For IDz enablement sessions, I have specific workflows, vocabulary, and functionality that I teach. I used these points and topics as markers to achieve my predetermined ROI threshold, deciding the following: if I can teach all these topics and execute all demos with a specific level of knowledge/usage, then I have achieved my set ROI. It’s that simple. I am able to do my work with the level of knowledge and usage that I have at present, and therefore, I am able to help people learn IDz and maintain my employment. ROI achieved.
But what about what I said earlier about usage level markers? This is where ROI gets interesting. Currently, my usage level is sufficient. But what happens when new releases of the software I teach become available? What about when someone from one of my classes asks a question I cannot answer on-the-fly and, through researching the question in order to provide an answer, I realize that I need to know more and might even need to update my class curriculum and materials? Well, simply put: my ROI has changed. The bar has been raised.
To bring this full circle, let’s apply these concepts and lines of thinking to an IDz rollout project. After the initial set of handshakes, upon receipt of IDz licenses, the rollout planning begins. One of the first data points that I advocate for project leads to consider is: where do you set your ROI bar? Is it enough to just have the tool installed, configured, and made available? What percentage of the developer community at your shop do you want to be using the tool, and at what percentage of working time? These questions need input from many people across many roles when considering what the ROI achievement marker will be for your rollout.
If the ROI goal is to get, say, 80% of developers using IDz 75% of the time, you will need to set clear expectations to the developer community and provide lots of support in order to achieve that. This support can include video-based learning materials, written materials, training sessions (and the time to attend), mentoring, user groups, or a Center of Excellence that developers can go to at any time to get their questions answered.
As time goes on and the rollout continues, you may find that the ROI bar you set previously needs to change. And that’s okay, that’s honestly extremely common. You use the software, you learn things about it, learn things about the development practices at your shop and how they change with the addition of the new tool and available functionality. This changes the variables and, inevitably, change the ROI markers. This is to be expected, and I would urge you to remember that ROI metrics are fluid. They can and will change. But that does not excuse anyone from having the conversation about ROI at the very beginning of a major transformational change in development practices. Trust me, you won’t regret having that talk.
If you’d like to learn more about ROI and the IDz rollout, or learn more about IDz in general, check out my classes, here’s a link.
Whatever workbench you choose, ROI plays a major role in success of tools rollouts. Remember this, and use ROI conversations and metrics to achieve your goals with these types of projects.