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.

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.

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.

There are many interesting project experiences involving testing. It is sometimes strange to see encounters that are déjà vu. This particular project is always repeating the same set of testing incidents with the same type of toxic testers. Like the previous project, nothing are willingly shared during the requirements workshop. The real project started in the testing phase where the user is known to test repeatedly the unknown datasets. For reference, we are running Waterfall Agile approach.

Testing is not Sharing

The test cases and scope should have been known but these people are well known information gatekeeper. In addition, you may encounter inexperienced noobs who cannot gather the right requirements or collaborate closely to break through the gatekeeper. It is always easy to feedback why have all these issues not be tested beforehand. Indeed, this would have been a useful comment if the information gatekeeper is willing to share the test scenarios.

Signs of Battling Testing

You will find these common tell tale signs of toxic tester when the user start to test on exception scenarios that are only known to the information gatekeeper. Do not be surprised or discouraged by the massive issues flagged. A typical development team will be battled by these type of toxic testers. The typical testing feedback will always be brief discouraging and laced with acidic comments. The key to handle toxic tester is to hold your ground and focus on fixing the critical issues.

Toxic testers will always be around in many projects. You are expected to see this type of testers when you have very brief workshop and limited information. You will also need to gear up with an Agile team to agile the high influx of reported issues.

Some projects loves issue log and issue reporting a lot. I greatly discourage these as they are a negative reporting compared to backlogs. You will also know this issue log comes from a waterfall approach. Thus, someone will try to run issue log like incident management. Although this is not wrong, there are some distinct differences between issue log and incident management that you must take note.

Incident is not Issue

An incident is an occurrence of event that stop the user from completing your task. This usually have priority and severity to the incident. Not all incident are issues, as they will need to be classify further. Usually, RCA (Root Cause Analysis) will be performed for severity 1 incident. The objective of incident is to clear the incident as fast as possible. This is also known as SLA (Service Level Agreement). Unlike incident, the objective of issue log is to permanently fix the issue. This is a key reason why incident management is different from issue log.

Incident is not a Change

Users often raise changes as incidents. A change is not clocked to SLA but classify as enhancement request. An experienced PM will be able to flag these request if this is a small project. Similarly, issue log is not for change. Any change to the intended scope will be logged as a change request (CR). The CR should not be critical to the project timeline.

Management of issue log must not be confused with incident management. If you really want to apply incident management to your issue log, then you must be aware that the rules are changed.