Less is More

In the UI/UX world, there is a design philosophy of “Less is More”. The best example is the battle of search engines where Google triumph over its rivals like Yahoo and Alta Vista with its bold landing page. I am still advocate of such design and clean uncluttered UI/UX still wow me over like Google.

Photo by Ethan Kwok
The Rationale of Less

I enjoy using the rule of 5 and 8 for UI/UX. This rule is related to the amount of short term memory users can remember. This, users enjoy simple approach to achieve their tasks. This can be 5 to 8 steps for achieving your system goals. You can relate this rule for 5 to 8 common menu or views. One such UI/UX features is the “Favorite” where you can bookmark your commonly used features.


There is a misconception of using RPA to overcome complex and misguided UI. Rather than using RPA, you should always seeks to improve the user experiences. UI/UX provides better approach to reduce users fatigues and steps without the need of additional overhead costs like RPA.

So, if you have a choice of investing in either UI/UX or RPA. Do go for the tried and tested UI/UX philosophy instead of looking at the novelty of RPA.

Art of Monitoring Data

Monitoring data is the most simple form of data analytics. Yet, this is more difficult to implement and the outcome is usually less than satisfactory. Users have the misconception that monitoring data is the same as extraction of data. There is little follow through on what to do with the data. Without clear sense of objectives and outcomes. data monitoring is just a dump and show ordeal and a waste of efforts for developers.

Monitoring Objectives

It is usual to see request to monitor data for sake of monitoring. This request is usually raise by non users who are eager to see how the system performs. These views from these set of users often do not have historically bearing and are based on hearsay or past experiences. You must evaluate and review the objectives on why and what you are monitoring. Be a devil advocate to query the objectives instead of agreeing blindly.

Monitoring Outcomes

There are two key outcomes from monitoring objectives. Do we meet the objectives? Or we do not? Follow through actions from data monitoring is key. This part is often neglected and left to its own devices. Users and Non Users must communicate if the objectives are not met. In a nutshell, the monitoring outcomes and its respective action plan must be clear and actionable.

Learning the art of monitoring data is the first step to learn data analytics. Setting clear objectives are the key to effective monitoring. If you do not have clear action plans, do consider not to waste developer efforts and extract data for the sake of monitoring.

Panademic Rollback

Our lifestyle is like a big system deployment. The Covid-19 pandemic has created another rollback to Phase 1.5 (aka Phase 2 Heightened Alert) in Singapore. It is time we get used to the roller coasters effect from the pandemic. What can these effects teach us?

Industry Channel Calibration

Single channel industry needs to undergo massive flexi calibration to multichannel. A major shift will be high touch industry. These roles will need to toggle between face to face services to digital services. It is no surprise that our feedbacks and emails suddenly get answered with slower responses due to overwhelming surge in online services. This lead to very poor satisfaction with online customer service. On the other hand, physical stores have to layoff staffs because there are no customers to serve.

Digitalisation Gap

The digitalisation effects create a huge gap in consumers due to the toggle measures of the pandemic. These gaps include IT savviness, vaccinated vs non vaccinated or even capabilities to provide digital presence. Sadly, those that fall behind will soon be forgotten as we get used to the pandemic effects or the new normal. It lends an important lesson to incumbent industries that pandemic can be a nasty disruptor for some or opportunities for others.

The roller coasters measures of pandemic will be anticipated. Meanwhile, the casualties will be tough to handle and damages be done. We can only calibrate our mindset forward to avoid the bottom end of the digitalisation chasm that comes with it.

Demo or POC

System demo is getting easier now. However, a demo is not to be mistaken for POC (Proof of Concept). Non IT users often cannot differentiate between demo and POC. Here are some quick tips to know the differences.

Demo vs POC

The distinct differences between demo and POC are related to time, scope and cost. Demo are faster to show because you will be using existing test or demo data. Demo scope is limited to standard features that have already been implemented. Best of all, demo usually is free of charge. In contrast, POC may not be free because you would be setting up customer data for POC. In some cases, you may configure specific features pertaining for customer requests. Thus, POC will take a longer duration to be planned and setup like a project.

Set Your Expectations

When you are going to showcase your system, it is important to set the customer expectations. Non IT users also have the misconception of using excel for simulation and anticipate the system to behave in similar manner. The expectations will determine if your customers are looking for a demo or POC. You will need to plan your schedule carefully based on these expectations.

It is not surprising to see sales or non IT users mixing up the customer expectations for demo or POC. You may find yourself in a crunch to provide freebies POC as a disguised demo. Therefore, it is timely to educate your users on the key points for demo and POC

Agile and PM Role

We have often know that there is no Project Manager (PM) role in Agile project. However, many organisations still retain the symbolic PM role. This is not cost effective and why does organisations preserve the PM role.

Why PM is Staying

Unfortunately, PM hold a great political position and influence for many organisations. While there is a shift from traditional waterfall to agile, PM role continues to remain for a main reason. That main reason is coordination. The PM role is now relegated to a coordinator role. This role is focused to coordinate the reporting between the project and management. In other words, this information gatekeeper role places the PM in an influential and yet non productive position.

Agile PM

Although Agile does not require PM, there is a dire need to remove information gatekeeper. Therefore, you are seeing an emerging role of Agile PM. This role are actually a hybrid of Agile developer or product owner who take on the additional efforts to connect with the management. In another words, they bridge the gap between Agile team and management. Effectively, this should remove the information gatekeeper influence and gap.

For many Agile team, we have agreed that there is no PM. However, the reality of PM existed for many organisations. These PM may not understood Agile and become information gatekeeper between Agile team and management. While a role of Agile PM is emerging, the battle continue to either remove or bridge the gap with Agile PM.

Why Interpreted Programming Languages?

Interpreted programming languages or also known as non compiled programming languages are getting popular with users within non computer science. You will know these popular interpreted programming languages as JavaScript, PHP and Python. Historically, organisations seldom decide on the flavours of programming languages in an outsourcing model. In today Cloud world, it is worth to consider what your vendors may be using for the programming languages. Why do you need a preference for interpreted programming languages?

Why Interpreted?

A major advantage of interpreted programming languages is ability to read the source codes. It is also lightweight than Java and can easily setup to run without much errors in the development environment. This makes it a great favourite with non computer science users. I am also one of those who have a preference over interpreted programming languages.

Users Self Service

The citizen programming community is getting really vibrant. This will translates to users in organisations. Compiled languages are machine codes and cannot be easily viewed by users if there is an error or bug. You will need to setup the development environment. For interpreted programming, you can self service to read the erroneous codes without the need of complex development environment.

If you are in the midst of Digital Transformation, it is time to review a preference towards interpreted programming language like JavaScript, PHP and Python. You can easily leverage on code savvy users to troubleshoot codes or have full access to the source codes.

Switch to Sustainable Energy

My son have an interesting school project to look into sustainable energy source for an island. The island will be the size of Singapore. One of tasks is the review of sustainable energy. He is required to find out the pros and cons of each energy sources. Fossil fuel is the default energy source for current usage.

Popular Sustainable Energy

Natural energy can come from light, wind or water. Popular choices of alternative energy are solar power, windmill or tidal. Solar farm remains the most popular choice in Singapore due to the constant sun in equator. Windmill is another popular choice but it is suited for large open space with strong winds. This choice is definitely out due to densely build up areas. Tidal energy is the most interesting but we seldom see these implemented. This could also be due to the small coastlines of Singapore.

Sustainable Ecosystem

The sustainable ecosystem is also a big challenge. The landscape have not been designed to hassle these energies. We have been so reliance on fossil fuels that the entire ecosystem consist of it. The switch to sustainable energy will be painful and costly. After all, existing demand and critical mass of fossil fuels are keeping the cost low, leaving consumers little incentive to switch to cleaner energy.

It will be a long journey to move to sustainable energy. Initiatives like solar farm are simple efforts to build these ecosystem. These pace are still slow but will Earth wait for consumers to switch. Only time will tell!

Customer is not Customisation

Many users or sales have the misconception of pleasing customer with promise of customisation to your system. However, this is not true as some services are better to be standardised and cost efficient. There is also a limit to please your customer without hurting your bottomline. What are the guidelines to avoid customising your system?

A Product View

Moving your business towards a product view is the first step to understand your customer base. A key reason of customisation is the fit of your product to customer needs. A poorly fit product will result up in a lot of customisation. You must adapt your product to fit the your targetted customer base. A well designed product should have a deviation of 10% customisation and 10% localisation.

Know your Customers

When you have decide to establish your application as a product, it it time to categorise your customer base. Your understanding of customers are important to refine your product into various types. High-end and well-paying customers can be provided with all the bells and whistles in applications. In contrast, you may not want an economic customers to be using your full featured product.

The basic guideline to stop the customisation trend for your application is to start thinking like a product. With a product view, you can position your application to each customer base. This will reduce your cost and increase your customer satisfaction with a better fit of product at valued pricing.

Hypercare 101

For the newbie in IT project, hypercare must be a new term. There are many approach to conducting hypercare. It can be confusing over the difference between standard support flow and Hypercare. Often, cost is proportional to the duration of Hypercare. This means that the longer the Hypercare period, the higher the cost. These are some of the standard methods used for you to understand Hypercare quickly.

Hypercare Basic

Hypercare consist of the following basic process and approach.

  • Assurance to fix bugs during the Hypercare period, also known as warranty.
  • Dedicated resources available during the Hypercare period.
  • Quicker turnaround to provide issue analysis similar to DevOps process.
Not in Hypercare

There are a few areas that are not covered in Hypercare. Notably, they are mainly related to changes.

  • Change management are not the scope of Hypercare.
  • User change request will fall outside of the Hypercare scope.
  • The Hypercare only covers the intended system. Related issues that are found to be caused by external system are not within Hypercare scope.

Hypercare is a common term used for project warranty. Like all warranty, it is constraint to the intended system and have conditions. The coverage and duration of Hypercare is proportional to the amount of money you are willing to fork out. Do be aware that Hypercare is not a God Mode that solve everything that happens after Go Live.

The Strengths of SOP

Today, I have a very interesting discussion on data modification process. There are two integrated systems with a constraint of one system accepting modified data. This is a very standard constraint in many networked applications. How should you overcome this constraint? This is where you need to have a very good SOP (Standard Operating Procedure).

SOP is Cost Effective

A good IT person should always learn business process and how to adapt SOP with system flow. Application does not work on its own but in support of SOP. In most cases, it is more cost effective to handle exception scenarios instead of customising. A good SOP works hand in hand with application. These combinations will lead to a balance trade off on standard applications with different customers.

SOP Simplifies

SOP helps to simplifies many business process. This allows your system flow to be direct and fast. A poorly designed system often exist with no SOP in place. The lack of governance leads to many data errors and system interlocking rules. Thus, you need to think of SOP as the approach to simplify your applications.

SOP exist long before IT have arrived. The full strengths of SOP can be realised in the tightly coupled systems. Without SOP, these coupled systems will hinder rather than accelerate your data flow.