The dark arts of the tech Roll Out

  • Home ยป The dark arts of the tech Roll Out
Change Management New Software Technology Roll Out Web Application Development

The dark arts of the tech Roll Out

By webgen 0

Having been working in IT since MS Windows 95/98 I’ve had some experience in how technology roll outs can succeed or suffer. For the last couple of decades I have worked on cloud technology before it was a thing. Nowadays we take for granted that “cloud” is really the only realistic option in most businesses cases.

My interest in computing started in the 80’s when I was about 9 writing in BASIC for “fun”. After studying Marketing Management I was put in charge of all things to do with the company brand and then the web came along and we had a firm build us a web site. Fast forward a few moments and I was asked to make changes to it. Opening up the source code it seemed straightforward enough and I started changing things.

And that’s when the magic happened and the fights started!

Change management in technology – even a brochure-ware web site like ours at that time – engaged the opinions and feedback of every stakeholder in the company. Management wanted it “shiny”, the Recruiters wanted a jobs board and the Administration team wanted applications to hit the CRM so that they didn’t have to do data entry. Suffice to say it was a worthwhile introduction to understanding the whole of organisation impact of technology change.

#1 ~ The role of technology change

In a small use case – for example only one person is going to use an application then it is worthwhile considering what their single needs and preferences are. If they are an expert at one product then forcing them on another one is going to require a learning curve and hamper their enthusiasm. That is a loss of productivity right there.

Typically the technology that is deployed in an organisation is far reaching and has many stakeholders. The primary decision to adopt new technology or retain an existing one should focus around a clear set of goals. What are you trying to achieve? Why? What problems are you solving? What are the barriers you will face? This becomes a key part of the next point.

#2 ~ People & Change

In Marketing we are taught about “buyer behaviour”. An example of this could be buying a new copier.

  • The sales team is frustrated that administration isn’t turning around their proposals
  • The administration team cites the current equipment as prone to failure which hampers their ability to produce the material required
  • The management is frustrated by the impact on sales
  • The finance team is concerned about cost of a new device

(I get that most material can and should be electronic and automatically produced from your CRM but this is an example!).

From a selling point of view the copier sales person needs to address a different message to offer a solution to each stakeholder’s problem.

When it comes to software sales the same is true. Unless there is a thorough needs analysis of all stakeholder’s needs then there are going to be issues. Worse still these issues are potentially going to be deal breakers as they come out months after you have signed up and parted with your cash.

The first essential step is to internally discuss the need for change with a representative of each stakeholder group and build a clear set of goals that are binding to the roll out of the project.

#3 ~ Selecting the right platform

Having worked in and around the Recruitment industry for most of my life it is ingrained that when hiring for a role you need to take discussions with clients and the material they provide and distil them into to key selection criteria. These are divided between those that are essential and desirable. Likewise you need to have a clear list of goals/objectives to communicate to a prospective vendor and also a feature list that gives them an understanding of what they need to address in their presentation.

Pro Tip: Don’t communicate to a vendor that they are all required because every platform has some degree of uniqueness. You may get a vendor decline to present because your wish list includes things they don’t have but they may have something better that you haven’t thought of! Just require them to be honest and please, PLEASE don’t make it an overly long list at the first point of engagement.

#4 ~ Tango

When engaging a vendor the first thing you should do is define a clear set of responsibilities of both parties. Wait; you didn’t think the vendor would do it all did you??? We all like certainty in our businesses (client & vendor) and working to a roll out plan requires a clear understanding of who does what and when. For example until the client provides the data to be imported into the new system the developers can’t work on the mapping. This tit for tat is run of the mill stuff because the vendor will only know a fraction of the idiosyncrasies of your business as much as you will rely on their expertise to commission your platform to your liking.

The best roll outs that I have been part of have always had a single point of contact that is engaged in the process. The worst is when one has to take direction from each stakeholder group for their part of the system. There is one simple reason for this: Once a stakeholder has influence over “the system” then the goal goes out the window. Worse still the rifts that can occur drain the energy of each stakeholder and the vendors themselves.

#5 ~ And here we are

So assuming that you have been happy with your UAT (User Acceptance testing) [fancy acronym “for you have tested the application and it does what you need”] you will “sign off” on a go live date. So when you go live there are going to be roughly three groups of users:

  • The users who are genuinely excited to have their problems solved and get on with the new platform
  • The “meh” group who really aren’t phased and will be bothering the first group for a few weeks asking “how do I do such and such??” (You did make sure you invested in training didn’t you?)
  • The naysayers “The old system was better”, “I can’t use this”, “How can I do my job now?!” – this group is kind of self selecting. If you stared out with a goal and the selection committee did their jobs right and communicated change to the team then that should have aided the change process.

Pro Tip – Vendors: The naysayers are the ones that are always going to come directly to you and find a problem for every solution. They are a valued part of your client’s team and deserve respect but this is why it is essential that you have a “go to” person on the client side to channel all feedback through. Working in a customer facing role whilst it is tempting to try to placate all of the users you run the risk of undermining your relationship with your primary contact if you provide a “back door” to every user.

#6 ~ Custom code can be one headache in two heads

Don’t get me wrong there are always room for innovations and ideas to extend a platform but it has to be approached with absolute clarity of what the requirements are and how they are met. Sometimes a client might have a vision of a killer feature but that can be poorly articulated by the client or poorly understood by the vendor. Or both.

Particularly in cloud software changes to the platform will affect all users so there is a reason why “can you move this button to the left hand side rather than the right” just aren’t possible to entertain. That being said there are pro’s and cons to requesting custom development on top of an existing platform.

Pros:

  • You will end up with a competitive advantage or gain an efficiency that elevates your business
  • You will be able to leverage more from the platform that compliments it’s strengths

Cons:

  • You potentially will need to invest in upgrades to your feature as the core platform is changed
  • Your feature is not core so the support team will generally not be as familiar with it when it comes to help desk

Most established platforms are more or less fully featured. You should carefully evaluate your specific needs against what the platform offers. There is a simple reason for this: vendors respond to market needs and these revolve around best practice and compliance and it just might mean you are straying off that path by inventing a new wheel.

#7 ~ Vendor Selection

Never buy a car from someone who can’t drive. There I said it.

What ever your business you need to make sure that your vendor has domain knowledge, preferably having direct exposure in your industry. A good vendor that fits your business has empathy with what you do and the problems you are trying to solve.

I hope that you found this article useful. If you want to discuss your situation further please reach out and contact us.

Thank you

Piers