Last week I had the pleasure of talking with friend and fellow IIBA Board director, Ken Fulmer. Ken spent 31 years at Sonoco and was their Chief Technology Officer. After leaving Sonoco he stayed in the oil and gas industry and was the CIO for a company based out of the southeastern US. Ken is also an active long term member of an organization called SIM (Society of Information Managers). Needless to say, he knows his stuff. During our conversation, he told me about an informal survey that he conducted at a recent SIM regional conference in Philadelphia. The 30 CIOs he spoke to revealed what is hot in their c-level role, how they view business analysis, the people performing business analysis and, in general, their other hot buttons.
One of those hot topics was how they were dealing with the complexity of new applications. Ken said the vast majority responded that their biggest initiatives were around implementing Commercial Off The Shelf (or COTS) software; COTS is where they are seeing the big demands. While there is continued need for the large massive package implementation in the ERP domain (with things like SAP or Oracle and People Soft kinds of applications), many of them are beyond that now. They are implementing other smaller applications into their eco-system that tie into the ERP domain applications. These smaller packages could range from anything like SalesForce.com to moving out of the accounting areas and into the sales and marketing areas as they automate support around those areas or into the plants and laboratories where they are doing research or manufacturing.
Ken also asked them about where they see the practice of business analysis. He heard that when using the little b, little a – they all thought business analysis was important because getting the requirements right is clearly something they know they need to value. In terms of the Business Analyst role (big B, big A) and the IIBA as an organization to support the role, three-fourths of them had never heard of the IIBA and many of them weren’t sure why it would be important to them – it’s not something they are looking to take any major initiatives around.
Since COTS implementations are a big part of a CIOs’ resources, I asked Ken if he discussed out of box implementations vs customizations. I commonly run into situations where CIOs put a line in the sand and demand a COTS application be implemented out of the box and processes will change rather than customize the software to adapt to the current process.
Ken heard the same thing in his conversations. He went on to say that is almost a universally accepted fact these days – “I’ve had in depth discussions with them about this and I know personally in my last 20 years at Sonoco, we never did anything that I would call customization. Now in this context, I am referring to customizing in the sense of changing the package delivered code.” He explained an acronym he associates with COTS packages called RICEF which covers the work you do when implementing a COTS package “Reporting, Interfaces, Conversion, Extensions, and Forms”. These are the actions that you do do to tailor or configure the package to meet your specific needs. In addition, there are always parameters within the package where you turn on certain features or leave other capabilities turned off. This is usually what people mean when they refer to package configurations.
Most of Ken’s experience and discussions in terms of business analysis challenges in implementing a COTS package are around the fact that you are trying to change your business practice to use the “best practice” that is representative of what the package is designed to do. Ken called this doing trade off analysis and gave the following example:
When implementing a COTS package, you have a common situation where people for the last x number of years have done business a certain way and that’s what they consider their practice and now a package comes along and says “you know, we don’t really accommodate that…we have a different way of handling it and you need to change”.
Now, instead of meeting the users’ requirements of “here is what I want, please give it to me” – it’s getting them to look at how they can solve the same fundamental business process problem in a different approach. It’s not right or wrong, it’s just different and it is the way the package has chosen to do it. With this comes about a business process change across all of those impacted – a process that needs to be managed so it’s a different approach to business analysis. It’s not just requirements gathering but very much about business process change and balance. Do we undergo the cost of coding up an extension or do we use the package with just the configuration options and adopt our processes to that? This kind of ability to do that trade off analysis and determine if it is worth it, is very much a skill that Ken believes needs to be developed in the business analysis tool kit.
Ken and I wrapped up our conversation with a discussion of where CIOs see large value in the BA community. Ken feels it is really around change management in terms of assisting them with bringing about that change. If an organization doesn’t completely understand what changes they’ve bought into the business, the project could fail. And, this is not due to a lack of what most people would call requirements. It is a lack of, or missing, implementation requirements not functional or non-functional. Looking at this concept in retrospect of several personal experiences, Ken feels that assisting in the planning for change is clearly a business analysis function. Stakeholder readiness is clearly in the BA role as well as on the back end, assuring that that change is actually implemented into the training plans and other non-technical aspects, including all of the implementation change at the procedural level. Issues manifest themselves often so in COTS because its nature is to change process directly. But change management issues can happen even when requirements are given to you from an internal group if that group doesn’t have all their stakeholders totally locked in.
I shared my view of this being the project around the project. Many times, the technical project gets done and is complete, but people aren’t thinking about the implementation side. The team that is needed to roll out the solution, assist with the impact to the business process, and confirm that is everyone ready to make the change seems to be forgotten. I told Ken that I viewed this as the harder part of the initiative.
This sparked a thought from Ken regarding the business analysis function around pre and post project phases. Within the context of a project once you define scope and budget, and you turn the business analyst loose to start flushing out the detailed requirements and working with the technical people to turn those into specifications…that is the classic role. On the outer edges of it though there are all the things like: How did you get the project to start with? How did you get the business case? What are the stakeholders? What are their issues? And making sure all of the stakeholders understand the change and are prepared to make the necessary process changes at the procedural level so they really know how to use the system – that also is part of the business analysis role.
I’ve always love the chance to hearing different points of view, especially one from a CIO. Thank you Ken for taking the time to speak with me and share your insights.