Categories
Risk Management

Sediakan Payung Sebelum Hujan

 

 

Sediakan Payung Sebelum Hujan

Hujan is still okay, but what if it is Storm? Again, here is a classic scenario as illustration purpose. 🙂 Here, we focus on the twist plot – no one resign but the whole office caught fire and all the laptops are destroyed completely.

Actually, this can really happen. Although Malaysia is fortunate enough to be protected by most natural disaster, we should not take this for granted. Disaster can still happen and the common ones are fire. Hence, Bank Negara (Central Bank) requires all the financial institution (FI) like banks to have Business Continuity Planning (BCP) or Business Continuity Management (BCM). The main objective is about RISK management.

file00093561951

In my previous company, we also performed this BCP every year by going to Bank Negara, restoring our core applications and ensure that our core applications works. I remember there was once I had a argument with my manager just because of I refused to ‘amend’ the BCP form, so that the company can ‘pass’ the BCP. Same goes with my current company when I was doing Terminal Quality Management (TQM) which is required my MasterCard for one of our products certification process. But, that’s another story all together 🙂

For more info – Operation Risk Management Concept Paper by Bank Negara Negara

 

Categories
Risk Management Software Engineering

The BIG Dilemma – Should I re-build the good old house?

One of the biggest consideration and dilemma as a software engineer is, should I re-design the system design and clean up the source code or not?

rebuild.

Here is a classic scenario as illustration purpose.

If Mutu’s source code is well designed and clean, Sally is considered lucky to pick up his role to continue and maintain his source code. Otherwise, it will be a nightmare for Sally to try to figure out his design and the dilemma on whether to clean up his source code. Why dilemma to re-design/revamp the system? Cleaning up code is good provided you are well-verse with the entire system design. The main benefit of a clean, organized and well-design system is maintainability. Although I don’t consider myself a talented software engineer, developing a well-maintained source code is one of my principles. I would rather spend a little more time to make the source code more maintainable, so that I don’t have to have sleepless night and headache troubleshooting bugs and for future enhancement.

But, for a large and critical system whereby there were many software engineers have ‘touch’ on the source code, usually new software engineer will opt to take the safer path by not making any unnecessarily big changes, be it to clean the source code or to re-design the system. Re-design the system can cause big impact to the entire system and highly susceptible to bugs too. Much effort is needed also to re-test the new re-vamped version.

Categories
Risk Management

This classic scenario rings a bell?

A team of five including the team lead, Wong are working on a software project. That project was given nine months time frame. The project went well and ‘on track’ for the first six month until one senior software engineer, Mutu tendered his resignation letter with one month notice. Upon receiving the ‘bad news’, Wong immediately notified the HR manager, Nurul. Few days later, she informed her staff to process for the new hiring. A week later, the advertisement was out in Jobstreet.

For the past six months, Wong and his team members including Mutu had been busy focusing in software development. Some documents were created along the way but there are ‘everywhere’. Some in his own laptop while some were in his team member’s laptop. That included the software modules in charged by Mutu. But these documents available are mainly high-level documents like use cases and initial functional specification.

Bear in mind, that Mutu is a quick-pace and strong-domain knowledge software engineer. Otherwise, he won’t sustain the in the company for four years. But, just like most software engineers, he hardly creates any own lower-level software document like flow-chat diagram, sequence diagram, test plan and release notes. Why? God knows. Maybe this is common among most software engineers; so that the company will always need and rely on them. But with software documents in place to understand the design of the system faster, they afraid that any new staff can replace them. Moreover, Wong also didn’t request for all the low-level of software document what. Maybe. Just my guessing.

At this point of time, the project time line is not longer ‘on track’ due to the extra time Mutu spend to prepare hand-over and for Wong’s time for Mutu’s hand-over sessions. All these hiccups were not factored in during project planning in the beginning. A week before left the company, he could only hand-over a couple of documents and all the source code to Wong. But due to heavy work load as a team leader, Wong has only limited time to attend and learn from Mutu’s hand-over sessions. Imagine how much stuff left over by someone who worked for four years. Hence, Wong just copied all those little software documents and all the source code in his external hard drive.

All in all, the hiring process took about two months. By the time, the new software engineer, Sally came in, Mutu had already left the company for a month. Wong met up with Sally and ask her to copy all the resources and Mutu’s source code from his external hard drive to her laptop and explain to her briefly the project they are working right now and ask to her those documents created by Mutu last time. As Sally went through those document, she realized that those software document are not in sync with the source code. Hence, she took quick a long time to really understand the modules developed by Mutu last time. And this cause more project delay and we all know time is money. The domino effects continue from one generation to another.


Two possible twist in the plot: Can the above scenario became worse? Can the project ‘survives’ and meet the project deadline? What if

  • Wong also resigned one week after Mutu tender his resignation letter.
  • No one resign but the whole office caught fire and all the laptops are destroyed completely.
Categories
Risk Management

Why some companies especially banks require their staff to take ‘Block Leave’?

In my previous company, every year, we need to take this mandatory block leave. It is a special annual leave whereby the annual leave is in a ‘block’ form once a year. During this period, the company is not allowed to contact you and vice versa. An executive level might have a longer block leave compare to a non-executive.

During your block leave period, if you company contacted you for some critical reasons, your block leave is considered void. And when it is void, you need to re-take the block leave again. If you do not have enough annual leave for your block leave, you need to take unpaid leave for your block leave.

 

Block-Leave

So, what is the purpose of a company imposing their staff to take block leave? The answer is risk management, to make sure that the company can still operate as usual without your presence. Just imagine, a bank has this only one employee who can support a critical system. And one fine day, he went missing in action. It can be due to many possibilities. Emergency. Accident. Critical illness. What will happened to the bank? Another word, by imposing block leave, this will ensure that there is replacement for every staff.

Not all company impose block leave, only those from banking industry or those companies which need to support critical systems.

Even with this scenario of senior software engineer resigned, the entire team is more prepared. At least, for the past four years, we know that the company survives when Mutu took block leave.

Categories
Risk Management

Software Documentation Management – The missing piece?

Puzzle

After working for more than ten years in several positions particularly within Software Development Life Cycle (SDLC), I come to this observation – software documentation management is lacking in most companies. Thus, it hurts the company greatly at the end. One of the most important benefits of having sufficient, quality and manageable software documentation is to minimize RISK. Let me explain. From the early stages until the end of the SDLC, some documents supposed to be produced.

Here is a classic scenario as illustration purpose.

A picture paints a thousand words

Imagine, which is a faster way for Wong to explain Mutu’s modules or for Sally to learn it? Reading 20, 000 lines of source code or looking at a some software documentation diagrams? Worst still these 20, 000 lines of ‘messy’ (i.e. with redundant similar functions or libraries) source code. Now wonder the employee turn over rate is high 🙂

Another beneficial reason of having proper software documentation like change request form and release notes document is to manage risk. I have seen some fire-fighting moments whereby the production system has so many bugs and unstable. Issues were escalated from one level to another level until the company had to hire a team of ‘specialist’ from oversea to cope and control the ‘fire’. So much money was spent.

At the end, the company decided to take so serious the importance of having proper process. Eventually new role was created just to focus on managing quality, process and risk and one way is by adopting Capability Maturity Model Integration (CMMI) Level 3 process model. After some months of learning CMMI, the ‘Process/Quality Manager’ then trained all roles which involve in SDLC, be it project manager, team leader, software engineer, software tester or application support engineer. It took a while to learn it. Initially, there were some complaints because of the hassle it caused. But, as time goes by, those process and template documents were refined to suit the need. Software engineers took longer time to release a fixes but what fixes released to the production system were much more stable than before. This is because the fixes were released and thoroughly tested by the software tester first before approve to be released to production environment.