Recycled Bullsh-IT

One of the joys of working in IT is the opportunity to play with new tech toys on a regular basis. Of course, by toys I mean Digital Transformation Technologies that will significantly increase business profitability/revenue/effectiveness/efficiency, etc. Or not, as is usually the case. The tech comes in two flavours:

• Thrills: Shiny new gizmos like Blockchain, code languages (Elixir, Rust, Go), SASE/Edge devices, plus anything usable for porn gaming entertainment, such as augmented reality, wearable tech, 4K projectors, etc.
• Tedium: Stuff you are told to implement because either some business exec has been nobbled by a sneaky vendor, or your investors also own a software company and have instructed you to use their unproven/bloated/unsuitable system

 It is always best to at least attempt to test the new tech before putting it live. Even if your sponsors & vendors don’t. So, what do you need to do to run a successful Tech Toy Trial? 

1. Clarity of Outcome. An effective Tech Toy Trial needs to provide each of the stakeholders with a clear benefit from taking part in the exercise. So, for business sponsors specifically, quantified business value (increased revenue, reduced costs, improved agility); for users, an easier life; for architects, a clear understanding of the impact of the Tech Toy on their standards; and for IT the impact on ongoing support skills, processes, and costs.
2. Rigorous Scope Management. One of the most difficult challenges with this type of Trial is that during the discovery phase of the exercise a number of additional potential benefits from the approach will be identified. The temptation is to add these to the scope to increase the overall benefit of the Trial. Unless you aggressively manage these additional benefits, you will lose control of the project. You are then likely to disappoint one or more of the stakeholder groups and will therefore have failed in the key objective of successfully completing the Trial. 
3. Tight Timeboxing. The most effective Tech Toy Trials I’ve have seen have lasted somewhere between 4 and 13 weeks, with a sweet spot around 6 weeks. Too short a time, and you cannot deliver enough value for anyone to take any notice of the exercise. Too long and the stakeholders will either lose interest or be dragged onto other more important activities, leaving you holding the nappy-filled baby.
4. Stakeholder Management. Involve the right people for the right amount of time. See Too Many Stakeholders. This will include the business sponsor, business problem owner, real users, business analysts, architects, IT management and Tech Toy experts. You will need a mixture of ruthlessness and pragmatism to ensure the right people are engaged at the right time in the project. 
5. Control the Technology. Make sure that you don’t try to change too much in one go. I have yet to come across a successful ‘Big Bang’ Tech Toy Trial where a completely new architecture is implemented in one go. Look for ways to incrementally introduce the specific architecture or tool that can add the most value to the Trials, and show it working with your existing systems before moving onto the next component. Incremental, or evolutionary, adoption of Tech Toy is proving more successful and sustainable than implementing the whole stack in one go. 
6. Play to Win. As your primary objective is to not get fired, ensure all participants gain value from the exercise and see the outcome as a success for them personally. Don’t get deflected by fancy features or a bullying sponsor. If any of the stakeholders don’t perceive sufficient value, you will have great difficulty in translating the Trials into mainstream production. See The CIO as Salesperson for some practical hints.

 If you follow these rules, there is a good chance the Trial will be successful, or at least dribble over the line.  If not, use your written (and backed up) audit trail to finger a fall guy so you live to die another day. 

John “Inspector Gadget” Moe