fbpx

Reactive is bad, Proactive is good, Strategic is best

Most IT organizations live and die by their ticketing system.   They measure their SLA’s of agreed to performance, speed of responsiveness, delivering projects to schedule and cost, and internal customer satisfaction, and consider themselves good partners.

They are … sort of … in an external third-party like way, but think about this:

  • Do you really want IT to think of themselves separate from the business?
  • If IT is reactive, doesn’t this mean that all business ideas are delayed while the IT solution is developed?  
  • If your IT people are reacting to business requests, how does differentiating technology gets introduced?
  • Should project success be defined as delivering on time and in the budget,  or by business value attainment?
  • What happened to innovation?

Reactive IT has its place, and that is in the day to day IT operations … keeping the lights on, if you will …   but for solving your business problems of today in a timely fashion, it fails.  To be more nimble, you need to be more Proactive. In some ways, this is what ushered the Cloud Model.  When it started the pitch wasn’t expense vs capital spend, but that NO IT WAS NEEDED!  Oh, its a lie, but why was this a good pitch?  Because traditional reactive IT has almost never been able to travel at the speed of business.  Business needs solutions quick, not months from now.

There are many ways to solve this.  Bimodal IT is one approach (two speed: slow and fast IT); solutions like Microsoft’s Power Apps, and Power BI, enables Citizen Developers to create solutions and not have to wait for IT; and then there are tons of platforms that support the rapid development of solutions.  I’ll briefly discuss Agile and DevOps below, but many companies also incorporate some of the ideas of Agile and DevOps to become Proactive (though many times they misuse these ideas, and end up in a mess).

Though these solutions appear Proactive, really they are just being reactive …. faster.  That is okay and certainly better than waiting months to solve a business problem of today, but there is an inherent problem to this approach:  Solutions are created which don’t work together; commonly are ad-hoc,  pulling data from non-standard methods or sources; and are nearly impossible to maintain.  The idea of the Citizen Developer sounds fantastic (at least to IT), but what happens when the Citizen Developer leaves?  Who is going to support it?  At the end, where these approaches improved speed, we just moved the problems into tomorrow.  We build a technical debt that will one day need to be paid. 

To be truly proactive (and not just reactive faster), you need to be strategic:

  • IT needs to establish better working relationships with other business leaders.  This doesn’t mean just having monthly prioritization meetings (that is a start), but becoming the trusted advisor to those leaders and understanding where they are bringing the business.  More on this as we discuss approaches.
  •  There needs to be a map (or maps) for the future.  Strategic planning at many companies can be challenged.  Sometimes the Strategy is nothing more than financial goals for the next few years.  Sure, its a start, but that is a goal, not a strategy.  Many companies will have Strategic Areas and allow people to tie their projects to them for funding.  This is also problematic since many executives will put their pet projects into a Strategic area so it gets funded, as opposed to coming up with the projects to meet the true Strategic objective.

    Still, this is okay.  Through strategic planning can be challenged, by working with the leaders you can understand what the company is really doing.  Each leader may have their own ideas, and it may not link together, but by understanding what makes the leaders tick, and their map for the future, an IT Executive can come up with a presumed vision of the future to have the discussion, gain agreement and plan out accordingly.

  • The foundation needs to be built.  No matter what, the foundation of what the business wants to do has to be built out.  If the company wants a Global Product Catalog, for example, some Product Information system needs to be in place.  In some cases, for example, disparent ERP systems, an Integration Layer needs to be built out.  When I speak of the foundation, I am speaking more than just the technology, but People, Process and Technology.  In reality, the People and Process side will (probably) take longer than the technology.

    Without this foundation, IT can’t truly get to be strategic.  It is okay since it can be a journey!

Approach – With Strategic being the goal, how can we move your  IT there?   What approaches work?

When I take on a new organization, I first inventory what assets we have (people, processes and technology).  Though the timing depends on the company (and its size), I initially concentrate on People (both IT and Executives), Processes (what is documented, who owns process improvement, etc.) Technology (okay, what do we have), and Vision of the future (where are we going, what is the maturity of the strategic deployment processes).  This should allow you to do a SWOT of the existing IT organization and environment, and build a basic approach to get buy-in from the business leaders. 

  • Establish core systems and rules of engagement – I am trained as an Enterprise Architect, so I like to link Business Domains and Capabilities to Systems, and early on determine the legacy systems which should build out the core of the IT footprint.  It can be as simple as a core matrix (Commercial Operations – Salesforce.Com; Production, Supply Chain and Finance – Oracle EBS; Office Productivity – Microsoft Office 365; HR – WorkDay)

    This concept helps since it can help establish your early rules of engagement and targets.  For example, in one company SFDC was used as a Development Platform and many Manufacturing Applications were developed under it.  This led to heavy customization, reduced capability for Sales since customer objects were used instead of the standard ones, and increased license fees for SFDC, Skuid AND  an integration platform. By focusing on Oracle EBS (and the Apex tool), the company will save hundreds of thousands of dollars in license fees and increased capability for the business.     

    This can also be a powerful tool for establishing different business partnerships.  We had one legacy tool (ETQ), which was a legacy tool for Quality, EHS and Compliance applications.  Though I COULD replace it by any number of tools, it was working well enough and was very well-liked by a certain executive.  By boxing it in for only specific business domains and capabilities, I was able to build credibility with the executive and turned him into an ally as we pushed the platform global (in its specific niche).

  • Understand and start a roadmap on the must-do foundational systems.  This may take years to fully implement, but create roadmaps to make it happen.  This work will need to be done while everything else is going on. but that is okay.  It is needed, but so is everything else, it is all about priority.
     
  • IT Organization– For the Application or Business Solutions, I have found a good working model is to have self-directed teams that align to the business functions.   The teams have responsibility for that function, so Business Analysts, Support Analysts, Super Users, System Administrators, Developers, all work together in an Agile or DevOps method for both new solutions, and support.

    The leader of the individual teams is usually an Architect, someone who can own the Business Relationship Management (BRM) for their function, and be a servant-leader of the team.  This can be a difficult position to hire for  (some of the Architects took almost a year to identify), depending on the area and the capability of the current team.  Having BRM  capability, enough technical knowledge to show the art of the possible and influence the business, and be able to run a self-directed team takes special people, but in the same company, I found six of them.

    You could have the Architects also be managers, but I always like to be able to flex my organizations to fix the current needs of the business.  I don’t want to have, for example, a Developers just sitting around doing nothing since there is no demand in that area.  To solve this, I have made my organization a matrix organization where there are resource managers who are separate from the team leaders. In this way, as an example, Developers can be “assigned” to a team based on the current requirements, and then change to another team as the demand changes.  This can also assist with cross-training and improved processes as the Manager owns the who and how IT is delivered for that function, and the leader owns the what and when.

    All the leaders (and managers) work together on the Enterprise Architecture, so where everyone is focusing on their specific area, it is viewed as part of the whole.
     

  • Embedded IT – I have found that many times it makes sense to have IT people sit with the business.  By having someone working with the business, either in a semi-permanent basis to provide day to day support, or just on a regular sit-down to shadow the functions, all sorts of problems can be uncovered, and sometimes fixed easily.  Two examples:
    • The Director of Customer Service was not aware that his Customer Service Reps are spending over an hour to create a quote.    By having someone shadow his people IT was able to see, recommend and implement actions that reduced the time immediately by 25%, and established longer-term initiatives that will reduce it an additional 75%.
    • In Manufacturing, we assigned a Support Analyst to sit with the operators on the manufacturing floor.   She had a seat back in IT and met with her team on a daily basis, but by being with manufacturing, she found that one of the primary challenges with the Manufacturing Execution System (MES) was a lack of training of the Operators.  She established the material and started training the operators, reducing failed transactions by 80%.
    • By embedding IT the Business Solutions team was able to get much more proactive, addressing problems the business wasn’t even asking us to fix yet.
  • Roadmaps  – With your organization in place, each team needs to be able to have a roadmap.  It could be something sophisticated (we started customizing ServiceNow ITBM), but it could be done with just Excel and  PowerPoint.  This allows discussions and horsetrading with the business on priorities within each team.  Until people can visualize the workload and understand the tradeoffs, IT can be seen as free, so they want a double portion and get it now!
  • Dev/Ops, Agile and Experimentation – These fundamental methods of delivery are fantastic to business alignment, but there are a number of aspects to consider:
    • Don’t confuse the tools with the actuality.  With this last company, they were doing what I call “Agile by being lazy.”  They had (and used)  Kanban boards, but they had no dates nor documentation.  Fundamentally nothing that would take more than a couple of Sprints ever got accomplished (I had a backlog going back over 8 years).
    • Experimentation and Citizen Development is fantastic, but there needs to be Guard Rails.  I had one project where a Market Portal was needed for Strategic Planning, but no one could explain to me what they really wanted.  After a couple of months of trying to get requirements gathered, I rolled up my sleeves and created a prototype.  Someone took it on after me, but the Prototype put up guard rails of what the scope was.

      This is the critical aspect, though the requirements may not be fully fleshed out, the Scope should be able to, even with Citizen Development, and you can create governance to ensure that the applications being developed (and accepted) fits in that rules of engagement we established in the beginning.  

I know this is all daunting, but it is achievable.  In my last organization we accomplished everything above, PLUS addressed two burning platforms, started the implementation of the foundational systems, and delivered about 30 significant quick wins, all within 20 months.  Though I drove the bus, I can’t take the credit, it was the awesome team that did all the hard work.  There were and are challenges but in another 16 months the foundation systems will be mainly implemented and the business will be on an accelerated path for growth.