Panademic Rollback

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ 1 Comment

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?

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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

~ Danny Kwok ~ Leave a comment

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.

Constant Delta

~ Danny Kwok ~ Leave a comment

Projects are usually encountered with a constant that is consistent. I like to call it a constant delta, oxymoron intended. For the noobs, this is frown upon and recorded as issues. Instead, a positive mindset is encouraged to embrace these delta. You will notice that Agile is unable to exist in organisational context due to traditional structures, policies and roles.

Another View of Delta

Delta management is rarely emphasised because traditional project management focus on fixing scope, time and cost. Variables are deemed to be risks with negative impacts for projects. This view of delta does not change until the recent explosion of Cloud technologies with Agile. The Agile project is a 180 degree view to regard change as constant. This paradigm shift to handle changes instead of freezing scope brings upon a new view of Delta.

Human Avoid Delta

Unfortunately, organisational view remains entrenched in fixed scope. The slow rate of change is consistent with human reluctance and avoidance to change. There are no revision of organisation policies or financial tools to manage delta. This lack of knowledge and uptake will persist for the next 5 years until all applications moved fully to Cloud.

Agile is the best technique to handle constant delta in projects. For many Agile practitioners, we are frustrated by the lack of delta management in the organisations. The gap between Agile and constant will remain unless there are more efforts to focus on how to incorporate delta within organisations.

Embracing Scope Creep

~ Danny Kwok ~ Leave a comment

Scope creep is one of the most common issues in all projects. It is so common that this should not be consider as an issue. Instead, it should be preemptively managed and anticipated. Scope is always constrained by time and cost.

Setting Anticipation

Project scope can be standardised in many aspect via Agile Templates. By using a baseline with templates, you can anticipate the extent of scope creep for your projects. Rather than setting expectations, you can set anticipation on the type of scope creep. This allows you to allocate the type of resources. High anticipation will result in the need of quality resources to manage scope creep.

Scope Creep is not an Issue

You may find many of the scope creep surfacing in issues logs. Thus, this will place a lot of stress for development team to clear the “issues” for Go Live. You should query the ROI (Returns On Investment) and justifications when such scope creep is listed as issue. For many cases, such issue end up as Change Request (CR) or Backlog items.

Scope creep is a staple of projects. It is time to embrace these human behaviour as scope is often underestimated. Therefore, we shall learn to embrace and manage scope creep wisely.