How You Deliver: Quality vs. Quantity

IT functions are known to be always busy with one project or the other in the typical modern enterprise. The pace of delivery is often a measure of efficiency and expertise. For many professionals, being able to say "we delivered 100 projects this month!" matters very much to their career. A busy job keeps adrenaline running high and gives a sense job security however true or false that notion might be. Your resume and LinkedIn profile are both fed by what you've done. There is no way for an interviewer - a stranger - to assess you except those metrics: the count of what you've done.

In this article, we shall ask six simple questions about technology-driven initiatives in the typical enterprise. Hopefully, the reader will reflect on the quality of what we build in our companies. Technology professionals will most likely connect better than others with the nuances of the thoughts expressed here. However, you are welcome to proceed no matter what your field of expertise is.

Six Questions About Your Last Initiative

1. How Many Outages Were Associated with Your Last Upgrade

Executives may be elated with the outcomes of your transformation project as they are described in your powerpoint presentations. But it could be that many end users are furious about how many times their daily routines were disrupted during and after the change. Stretching it further, they have only chosen to live with all the things they can no longer do because of your bright idea. Are they happy with the new status quo or are they just agreeing to live and let live?

Maybe if they were more authentic, they would voice out how tacky technology is to them. Most people are empathetic though; they would rather not be responsible for someone losing capacity to take care of their families.

You know it reminds me of the rancour that would typically ensue over twenty years ago when Titilola Anidugbe 's awesome 微软 Excel templates back then would help us calculate the cost of outages in our incident reports.

2. How Many Users Know How to Use the New Features

Users are very impressed with the fancy new features you showed off at the training but are unable to use those features beyond the class. What was taught them during the knowledge sharing session is not relevant to their daily jobs. In any case, they had no say in what the training content. Would it make sense to engage users on how they think new technology should be used?

In the world of business, we are often told that the customer does not care about what your product can do, they are more concerned about what it can do for them. It is a case of features for their own sake versus features that help users address pains or create gains i.e. deliver capabilities more efficiently. Think about it, how many features on your Android++ or 苹果 iPhone do you use on a regular basis?

3. Do Your Users Know Who to Call When Things Go Awry?

You made sure all the i's were dotted and the t's cross but restricted yourself to the technology components. There is no clarity as to who is responsible for making sure the new app is always up and no one to ask when we are confused. The builders made the assumption that everything will always work as planned post go-live.

When we make such assumptions, we typically leave out the design and deployment of redundant components, escalation matrices, documented procedures, detailed architecture artefacts and so forth. These non-technical aspects are necessary for a solution that delivers value sustainably.

4. How Long Does it Take to Respond to Your Users?

Every new technology initiative is an opportunity to refine the relationship with users and other stakeholders. In formal scenarios the terms of such relationships are defined in contracts - SLAs, OLAs and the likes. As much as users want to be assured that technology is reliable, they also want to be sure support is available. Support structures should be part of the design of new solutions.

"Can we count on you to come to our aid when things don't go as planned?"        

5. What Groups, Processes and Systems are Impacted by What You've Done?

Your new technology solution is going to be used by people executing business processes. If they are unable to do this efficiently, they will abandon the solution and revert to whatever it was they are previously used to. Back in the day, there was the story of the Point of Sale (PoS) terminals of a certain bank which were often abandoned under the desks of merchants at their shops. Hilarious but instructive.

If you have not aligned processes with how the new technology works, you might just have released a complication not a solution. Understanding relationships across the people, process and technology dimensions is vital for the next iteration of transformation. If this understanding is not evolving within the enterprise as it becomes more complex, mistakes will be repeated too often.

6. Will Your Solution Still Be Useful, Used after You've Left the Company?

Attrition is the name of the game in the modern corporate landscape. No matter what we do, Gen Z's and younger want to keep their freedom particulalry in the tech industry. Employees will move on. What do you do when the key developers that built your last best application are poached by the next best company? Destroy the app and start over?

Solutions should be built to last so, it makes sense to question whether we have derived sufficient business value from the last technology before acquiring a new one. Humans will do whatever is easy and beneficial to them. Governance of some sort is an effort to make sure that they are doing benefits the organization as well.

Recommendations for Deepening Quality

Here are a few thoughts on postures that may help improve the quality of your next transformation initiative.

Give Architecture It's Place

Whenever we talk about architecture as technology professionals, the picture that flashes in the minds of many people is a bunch of servers joined to one another with lines. Architecture is not always about the technical components.

Think about architecture as understaning and brainstorming relationships - technical and not technical. Architecting is a way of thinking before doing; planning before implementation; getting a shared understanding of WHAT we are building.

Frameworks are great in that they help you formalize that philosophy of thinking before doing. Our obsession with using or not using frameworks (which may be perceived as blockers) should not rob us of the basic philosophy of evaluation before execution.

Carry Stakeholders Along

Whether it is the executives who need to back what is about to happen or the users who need to know what is happening, getting people to come with you on the journey is incredibly useful. Almost every professional worth their salt is always familiar with the need to get executive buy-in.

If we are are going to declare lasting success, your breakthrough idea must really help users do their jobs better. It begins with requirements gathering, is solidified by knowledge transfer and is sustained with feedback loops.

Broaden and Deepen Documentation

The typical set of architecture artefacts will comprise views that speak to at least four domains - business, data, application and technology. The majority of opinions in today's world have it that most people do not read long documents or review complex diagrams. But think about it, when last did you pick up the mechanical drawings of your home as leasure reading?

We don't use our documents because they are not sufficient for our needs or because we choose not to. If our solutions last long enough to be maintained, what we know about them will be useful on the day we need it to be. Beyond this, however, is the clarity how support, availability, cost and others are handled.

Conclusion

We are often caught in the dilemma of how deep is too deep when thinking through our next transformation project. Is the effort applied to getting everything right worth it in an age of rapid change? Probabaly not. Will our extensive list of documents matter in a few months? Well, it depends.

Every organization has to arrive at the right balance between the extremes of analysis paralysis and chaotic execution, between governance and recklessness, between quality and quantity. My point of view is that if the organization is interested in sustainable transformation, quality is key.

So, where does the pendulum swing in your case?