When I was a boy, there were times the older kids would take off ahead of me to the ballpark or community pool. Or, I’d get spurned by a young, freckle-faced redhead (yet again). Either way, I would find my way to Grampa’s house for consolation. On these occasions, I would reach his house and slam the screen door behind me – grumbling about how the town wasn’t good enough. If I only had a better baseball mitt, cooler clothes, or some other excuse for why the world was not turning in my favor.
After, Gramps would open a bottle of root beer or grape Crush to share with me while asking his inevitable question: “What’s really ailing you, boy?” As we talked through the issue I found out that what was ailing me was usually something I could fix within my own self. The power was within me to change outcomes.
As a much older, hopefully wiser, management consultant who helps organizations determine what’s ailing them, such as the need for a new ERP system, advanced tool set, or improved technology platform, I find myself asking the same question to my clients: “What’s really ailing you?” As it turns out, they usually can do a lot on their own to fix their issues. I find businesses often seek large improvements that actually serve as a distraction from the problems that are really plaguing them.
When I start talking to leaders, I quickly learn that the solution they seek will not resolve the ineffectiveness they are experiencing. I am often brought into an organization to implement a new application or evaluate a new tool set when a simple process change can make a huge and less costly improvement.
There are three consistent complaints that business users have with their IT department:
- Ideas, initiatives, and desired changes are submitted to IT and then seem to go into a black hole. The user never knows if, or when, a change will be completed.
- Whatever IT delivers, takes longer and costs more than expected or promised.
- When initiatives are delivered from IT, they don’t work as intended and/or are as well developed as when the idea was sold.
Leaders often decide that these three ailments are the result of antiquated systems. Often this leads to a decision to get a new system, a new tool set, or re-organize. And sometimes, leaders are dismissed for failing to react to these perceptions.
The newest “instant fixes” now come by way of the cloud, IoT and Mobility. Leaders have bought into the “Bi-Modal IT” concept and decide that what must be ailing them is a need to get to the “cloud”, run SAP on HANA, or build a huge data warehouse. Whatever it is that is negatively impacting their success, the newest, fastest shiniest toy will certainly fix what’s wrong with their IT department, especially when an executive from the business side has put a bug in their ear about it. I challenge that if the IT organization is already struggling with an ability to effectively deliver, adding a higher degree of complexity and sophistication isn’t going to improve conditions. It’s the classic CIO Paradox. Leaders have to find a way to innovate and prove they add value to the business while dealing with complex legacy integrations and interfaces which take away focus, time and money from innovation.
I suggest three significant changes that will improve IT delivery and the perception of business stakeholders. As we move through the fiscal year and the stock market continues to be volatile, budgets remain uncertain, and, while you strive to add value, I implore you to consider making the following changes. Take the three steps I outline below. Whether you are planning a big initiative, buying a new ERP, re-organizing, or maintaining the status quo you should try these steps. Doing this will improve consistency and build better IT/business alignment because you can measure and show results.
Create an effective demand management process, one that will provide visibility to changes and where they are at in the pipeline. Do whatever you can to minimize the perception from business that changes go into a black hole. One of the most frequent complaints I get from both business and IT is the inability to manage demand effectively. IT organizations receive changes from multiple sources, track those changes in multiple tools, and can rarely provide an accurate accounting of the change to their business partner. They can’t say when it will start, when it will be done, or where it is in priority to other changes.
If you have ever ordered a pizza online from Dominoes they have a neat graphic that tells you when the call is received, what worker has prepared the pizza, what time they put it in the oven, when it is scheduled to come out of the oven, and finally what time it left the store for delivery to you. They show a little guy picking up the phone, then putting a pizza in the oven. It’s fun to watch on line while you wait. My first suggestion for this year is to streamline the demand management process within your organization. Seek a single entry point for all ideas and demand and consolidate that demand so you have visibility and create communication mechanisms that will inform the business of exactly where their change is at within the change management lifecycle. A lot of high-level managers I talk with have an impression that they are better at demand management than they really are, because they know their systems and processes and fail to see the way their customer perceives them. Your business partners will be more likely to work with you, and less likely to complain, if they understand exactly where they need to enter a change, when the change is approved or rejected, and when that change will be carried out. More specifically, they need to be just as involved in that process as IT.
Creating a single point of entry for demand, managing that demand, utilizing effective communication, and building metrics around progress will improve business perception. Communicating these four simple measurements will go a long way:
- Your change was entered on “X” date.
- It is currently at “X” stage in the lifecycle.
- We anticipate your change will be done on “X” date.
- You will be notified again when the following “X” event happens.
Many leaders I talk to believe they are effectively providing this level of visibility but actually can’t do it. They can’t provide visibility while the change is in process or in a manner where the customer can retrieve the data on their own (like the pizza delivery graphic). They can usually find someone on their staff who can tell them, but that person is probably looking in two or three places and then asking someone else about the details.
Create a release process that provides regular intervals to production on a timely, reliable basis. Just as the Domino’s pizza gets constructed, (fed into the oven, packaged and sent out for delivery), the process of changes moving through your System Development Lifecycle should be just as predictable. This second area of improvement can make a drastic change in the perception of your IT department. Creating a standardized rapid release process can be done whether you are just starting a large initiative, in the midst of an implementation, or in a steady state mode. It’s all about getting into a rhythm that can be timed with individual business and product lifecycles.
Make a concentrated effort to improve the overall release process for changes and code development. Once the demand process is streamlined you can get a grasp of capacity. Your business customers can understand the rhythm and begin to operate within the boundaries of the release cadence. They will better understand when requests must be entered in order to hit a certain move to production date. Once you are in synch with your business customers you can turn attention to quality. You can begin to improve the processes around development, testing, and deployment of your initiatives. Many organizations have change control – and, even more, are developing true release management. A lot of leaders assume they do it well. It is so intuitive, yet most IT departments can improve greatly in this area.
A related issue along the same lines as having no release management process is having too many. When an organization has multiple change and release processes depending on the application, business customers can get lost in the administration of changes. Each application may have, but need not have, its own system development lifecycle. In so many cases, regardless of the variations of software technologies, platforms and coding changes, the actual release process, tools used to move code, and change documentation can be standardized.
The third suggestion for fast improvement is also the trickiest because organizations sometimes have the impression that since they have always been testing, they’re already optimized as much as possible. Step three is to make a concentrated focus in application testing. As your IT organization moves from the traditional enterprise structure to the more fluid and agile DevOps teams, they need to get the most from their tool sets (not just testing). Sometimes when leaders have invested in large expensive test tools, they assume that they are also, by default, fully utilizing the tools. This is usually not the case.
Organizations often have very little of their test cases automated and rarely have their test cases designed or organized so that they are re-usable. This is in part due to the assumption that since they have invested in tools, they should be able to reduce headcount (it’s usually one of the selling points in the sales pitch for a tool). When they buy the tools, they instantly reduce the administrator roles needed to accurately and completely setup the test tool needed to gain full ROI. I do not have statistical numbers, but it is safe to say most organizations I have encountered are understaffed in their tools infrastructure team. The result is tools get implemented minus key functionality. If you buy the tool but don’t staff enough people to leverage key functionality, you have wasted your money.
Tools and their usage aside, I would say that testing gets less time and attention than other phases of a development cycle. The design and build phases tend to run long and take too much time in the overall project timeline. Rather than push a go-live date, we shorten test cycles and all but eliminate performance testing. The result of that action shows itself in extended hyper care periods after go-live.
Come on, admit it. I have never, in 20 years, worked on an initiative (particularly large ERP initiatives) that did not sacrifice a huge chunk of testing time in favor of moving a go-live date. When testing is unorganized in the first place, and then minimized due to time constraints, it becomes ineffective. Defects are introduced into the production environment, and the business is disappointed; users lose faith in IT to the point where IT loses funding for more initiatives. They have to funnel funds into fixing what they just put into production because it wasn’t tested well. Ultimately, the business customer spends even more money while getting less than what they asked for in the first place.
If you want to improve right now, please don’t look to the newest tool or software as your first option. Take a look at what’s really ailing you. Look to decrease the three common complaints the business has with IT which are limited visibility, high costs in time and money, and lower quality than expected. Take the three steps I have provided and make these three changes your focus instead of evaluating new tools and software. Eliminate the business’s impression that their requests fall into a black hole by improving the demand funnel and capturing and communicating the status of changes in a manner that is simple and easy for the users to access. Reduce time to delivery and inconsistent success by developing, standardizing and improving release management practices. Finally, focus on improving testing to match rapid DevOps and Agile release methodologies. Create processes that will allow for more time in testing while at the same time speeding up your testing methods. If you take these three steps and make these three changes in focus, you will decrease production defects, increase funding for new initiatives rather than defect repair, and increase your own time for innovation. Being able to measure the improved rate of success will mean added dollars allocated to IT and allow you to become a partner and revenue generator. So what’s really ailing you? It’s probably not that you need a new data center, new platform, or new analytics system. It’s probably a lack of sound Application Lifecycle Management and that’s something within your control to improve.