Basic Plan, Minimal Requirements Lead To Surprising Results
March 31, 2014 Dan Burger
When IT budgets are constrained and IT staffing is obligated to maintain existing infrastructure, the adoption of new technologies often relies on long-term and sometimes short-term cost savings. These are spelled out as return on investment (ROI) and often have implementations that are outsourced to software vendors, systems integrators, and consultants who can get the job done quickly and with as little disruption to the day-to-day business processes as possible. Trevor Perry spends most of his time in that tricky environment with one foot on the dock and the other in the canoe.
Perry has application modernization skills, whereas most IBM midrange shops do not. That makes him somewhat of a hired gun. To my knowledge, he hasn’t shot anyone. He hasn’t told me that thought has ever crossed his mind, but nonetheless I think it might have. Application modernization projects, from what I have been told by Perry and others, are often a shot in the dark–not that more fail than succeed, but that planning and expectations are lower than what they should be.
Perry, the IT strategist and modernization specialist, enjoys being the one who turns on the lights.
The description of a standard modernization project is straightforward: Let’s change from green-on-black, text-based, multiple-screen, navigationally challenged applications to a graphical user interface that fits in with 99 percent of the world recognizes and is comfortable using and deliver it through Windows or the Web. That’s a fine start, but it usually ends there as well. After that, there’s no idea what the app will look like, or how it will benefit workflow and function.
Here’s a possible scenario that may sound familiar: An executive edict arrives via thunderbolt. It’s short and to the point. “You guys in IT are going to fix things so we don’t have to see another green screen or I will personally toss that AS/400 thing–he doesn’t know it’s not called that any more–out the window.” The developers need ideas and they need them fast. This can lead to some bad planning that often leads to some surprising results.
“Rarely do people have a fleshed out modernization plan,” says Perry, the most vocal of the IBM i advocates that come to mind. “They have a basic plan with minimal requirements until they find out what is possible. Then their expectations are often exceeded. They realize they can get much more out of their investment.”
You would think there would be more pre-planning for these projects, but in reality there isn’t.
The idea that a modernization project can be strengthened as the project develops helps build momentum, a tactic that Perry knows well. Still, he acknowledges that companies that better define what is needed from the start find smoother sailing.
“Customers are aware of benefits. They rave about the benefits,” the modernization propulsionist says. “For instance, the order entry people were the first to get the benefits in a particular company I worked with. After the purchasing department saw what was available, they wanted some of that. Those situations give companies the opinion that it is worth moving on to additional projects.”
Productivity gains don’t go unnoticed, but it is rare that companies measure the costs, benefits, value, and payback period. Just because an application looks better doesn’t mean it will increase productivity. Still, I hear IT managers and executives claim productivity gains measured only with the eyeball method while saying they would not attempt a project that doesn’t have a measurable ROI. When data is spread over three applications before it is modernized and incorporated into one application after modernization, there likely will be measurable productivity gains. Do that for several applications–in some instances it could involve more than three screens folded into one–and it’s hard to argue against productivity gains.
“Once companies see some results,” Perry says, “it becomes easier for them to see where the most value can be realized. If doing this one small piece creates X amount of efficiency, then it’s a better bet that this piece over here will create greater efficiencies.”
But new applications don’t automatically come with high performance. Some are slow and they lead to projects being dropped. In those cases, the project may be switched to a different vendor or the company may retreat to the green screen.
That may be a factor in why budgets are restricted in IBM i shops, but it is not a big factor. Technology implementations are seldom, if ever, a sure bet. Failure and disappointments are as much a part of business as they are of life. So budgets would be tight regardless of the road kill that occurs.
But on the topic of budgets and modernization projects, Perry described two types of projects and budgets, which are applicable to companies that have only done green-screen app dev in the past.
The first is defined by a company that outsources the modernization project and the budget is set using estimated application development costs and separate implementation costs. These are typically deadline-driven projects, for companies with IT staffs that aren’t matched to the project time frame and skills requirements.
It is a growing trend to outsource modernization projects, Perry says. With this choice, existing IT staff is not disrupted and the people put on the project are very familiar with the modernization technology. However, as Perry points out, those who aren’t employees of the company don’t know the company’s business, so they should not be left to work in a vacuum. Projects benefit by the involvement of business units affected by the project, including some that may not be apparent. The graphics department, for example, keeps the appearance of new applications in accordance with company marketing strategies.
Nearly all companies plan to take over the maintenance of the modernized applications at some point rather than have the vendor maintain it, Perry says based on his experience. After the first project is completed and the company is comfortable with the accomplishment, the project is planned to teach staff to handle subsequent projects.
Obviously, the IT department needs to be ready for this phase. Stories of outside consultants who never leave are usually keeping someone from sleeping well at night.
If the company decides to do the project on its own, there is the cost of the software, but the development costs are already accounted for in the existing RPG programmers who will learn to be modernization developers. Their time that was formerly devoted to green-screen development gets applied to GUI development. That cost doesn’t go into a modernization project budget because they are already on staff. Companies don’t see the labor of their own people as a new budget item. They realize, however, that those people will need to acquire new skills and that will slow the project, but the training isn’t part of the budget either. Most of these projects, Perry says, are not under deadline pressure.
“For a lot of companies, eliminating the green screen is not a priority. They have other priorities,” he says.
The majority of modernization projects are relatively small and designed to eliminate specific pain points in an organization. This leads to a debate about the value of tactical projects compared to strategic projects. Perry believes that big picture planning takes a back seat to the attention given to putting out fires.
Strategic planning involves rounding up the necessary resources and looking beyond a single project or a series of individual projects, even though the short completion times–usually based on a subset of one application–and smaller costs are attractive. A phased implementation is a wise choice unless it randomly sprouts a weed patch instead of a garden.
“I don’t see modernization in the IBM i community as being strategic to the majority of businesses,” Perry says, but he is also encouraged by a prevailing “show me how” attitude from many organizations. “The more they are exposed, the more amazing things they find,” Perry says.