Engaging All Service Engineering Folks: Help Forrester Define “Service Engineering” As A New Role Within Infrastructure & Operations (Or Beyond)! A variety of technology trends such as mobility and clouds are empowering consumers and connects employees who all are interacting and collaborating through apps and devices which are changing the way business is conducted. In response, organizations are forced to accelerate business changes which require the need for agility innovating new technology choices, implementation options, and delivery approaches. In this new pace of change the business demands more of IT to help deliver services which enable and support the age of the customer. Some Infrastructure & Operations teams have made the transformation to manage and support BT services which consist of technology, systems, and processes to win, serve and retain customers. Other organizations still manage and support components which range from operating systems, middleware, general purpose components, applications and custom components built all for specific purposes. I&O teams have become good at building components, but it often lacks the engineering discipline to assemble these components into services that meet specific business needs and are relevant in the age of the customer. To stay relevant and transform Infrastructure & Operations in the age of the customer, I&O needs a new role – service engineering. Service engineers mainly “do” three things:
1. Think and act from the outside-in – this means establishing, managing and continually improving services which are critical and essential for business enablement and business success.
2. Participate and support the DevOps journey – business agility in large parts depends on technology today. The DevOps team plays a large role in the quality and speed of technology delivery.
I read this somewhere recently – I think it was the CIO of Intel, Kim Stevenson (quoting IT folklore). But it stuck in my mind, long after the link that I harvested it from had evaporated. I like it since it gets to the heart of the discussion . . . what’s the business problem you are trying to solve. So often I find myself fielding queries where the people on the other end of the phone have decided on a technological solution (a hammer), and are now looking for a problem (the right nail).
The business doesn’t want a hammer or a nail; they want something of value – the house. It’s not important that your solution has this product or that techno buzzword. They don’t care for how cute your big data credentials are, or whether your mobile mojo has trumped your social ace in the hole. These sorts of trends – big data, mobile, social – are just like, well, like the context within which the house sits.
Of course, we need that application delivered to our customers on a digital device nearby to them. Of course, we want that engagement to leverage the history of what we’ve done with that customer in the past – their wants and preferences taken into account. Of course, we want to leverage what we know others in the same context considered the right choice. But we also expect the customer to channel-hop to the Web, and then perhaps wander into a branch or store, and ring up about it to see where things are at (WISMO – what is the status of my order).
The data shows that 70% of corporate change efforts either totally fail, have lukewarm results, or the change never becomes an integral part of the company culture. As I talk to clients about their change efforts, what’s worked and what hasn’t, some clear patterns emerge.
Change is not an event — it’s a process. You make plans for the executive to announce the change to employees. The executive talks about why it’s important for the company to make the change, what the change will look like, and the assistance the company will provide employees during this transformation process. The executive responds to employee questions and recommends that employees discuss any additional questions with their managers. A thoughtful speech, well delivered with empathy around challenges of change . . . it’s good, but it’s not enough. The executives have been thinking about and planning this transformation for weeks or months and know it well. The employees are hearing about the change for the first time, in this hour-long, all-hands company presentation. Anxiety, shock, and fear are typical reactions. Rather than this one-time announcement, make sure executives explain that today’s meeting is the first of many that will be held periodically using different media (web, in-person, email, social network, etc.) to provide updates and answer questions. Remember, half the audience may have heard nothing beyond the statement that major change is going to happen. Fear set in and they began to think about how this change will affect them.
I was talking with a client the other day about the reporting structure of her applications organization. The group had a single leader, but underneath, it was subdivided into groups that were a combination of technology (website, data analytics, intranet), business unit (four major ones), and IT processes (QA). The leader of this group knew that every organization is different based on the culture, size, maturity of managers and a dozen other factors. However, she was seeing a lot of friction between groups and wanted to know what structural changes other organizations had made and what the tradeoffs were.
We started by talking about the direction of the organization. In particular, she needed to determine if the business units were moving to greater integration of their data and processes or whether the business silos formed were just fine. Though most organizations are moving to greater integration, this is not an obvious answer, as some companies have run-off business areas that are in maintenance mode and may be kept separate. For this call, she asked that we assume the company needed greater integration. There were other drivers around growth and cost containment that we discussed as well.
I recently finalized a report* on software asset (SA) based IT services, this time looking at vendors’ best practices in terms of governance, organization, skills, tools, and processes. Needless to say, the move to software asset-based services will have a huge impact on the traditional operating models of IT services firms.
Obviously, IT services firms need to learn from their large software partners to understand and implement specific software asset management processes such as product sales incentive schemes, product management, product engineering, and release management.
This will induce a formidable cultural change within the IT services vendor’s organization, somewhat similar to the change Western IT service providers had to undergo 10 years ago when they finally embraced offshore delivery models.
I see a few critical steps that IT services firms need to take in order to facilitate this shift towards software asset-based business models:
Build a client-relevant SA strategy. Building an SA base offering is not (only) about doing an inventory of the existing intellectual property (IP) that you have on employee hard drives and team servers. More importantly, it’s about making sense of this IP and building strategic offerings that are relevant to your clients by centering them aounrd your clients’ most critical business challenges.
Applications development people can't stand the Luddites in the operations group, and ops people hate those prima donas in apps dev - at least that's what we are led to believe. To explore the issue, two of my colleagues who write to the infrastructure and operations (I&O) role - Glenn O'Donnell and Evelyn (Hubbert) Oehrlich - invited me to participate in an experiment of sorts. They arranged a joint session for the I&O Forrester Leadership Board (FLB) meeting, and I was the sole applications guy in the room - a conduit for I&O FLB members to vent their frustration at their apps dev peers. For those who aren't aware, FLBs are communities of like-minded folks in the same role who meet several times a year to network, share their experiences, guide research, and address the issues that affect their role.
We infused the session with equal parts education, calls for joint strategic planning across all IT work, and a bit of stand-up comedy - Glenn noted that as representatives of our respective roles, he and I were actually twin sons of different mothers. I noted that in that context that our parents must have been really ugly. Once we opened the session for discussion, the good folks in the room wasted no time in launching verbal stones my way. Now, I'm no IT neophyte: I've been in the industry since 1982, and I'm no stranger to conflict - I grew up with 3 older brothers, and we all exchanged our fair share of abuse as siblings will. Still, I wasn't quite prepared for the venting that followed. To summarize a few of the main points, I&O sees apps folks as:
At the upcoming IT Forum in Las Vegas (May 26-28), I will be collaborating with Bill Band on a piece around using the customer experience to drive breakthrough process improvement, and with it, business performance. When you think about it, satisfying the needs of customers is what all business is about (OK you could argue that governmental organizations don’t have customers, they deal with the needs of citizens, but you get my drift).
In the first part of our presentation we will present research to support the view that improving the outcomes delivered to customers adds dollars to the bottom line of the business. Then I will switch to a theme dear to my heart -- that Business Process is at the heart of all significant Customer Experience efforts. And that comes down to:
How We Do What We Do -- Of course, the relationship between the Customer Experience, and how you do things, is pretty clear. I put this in the category of “Doing Things Right” -- i.e., the way in which the processes of the firm work and the employee behaviors.
What We Do -- But in order to deliver compelling customer outcomes, it’s also a question of “Doing The Right Things.” Which is about the business offering -- the services of the organization and the components that make it up. The business capabilities are, of course, a better way of thinking about this rather than the org chart (which is what so many folks seem to do ... decomposition of the org chart as a way of understanding processes).
Why We Do It -- And then it comes back to why we do this, and how it implements organizational strategy and the impact/benefit to the overall brand.