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.
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: