How does data become light, travel thousands of miles and become data again?

The Data Inside a Cable

You’re at your PC and you type “Hello World”. This gets converted into binary which is a number system comprising of only 1s and 0s. Example:

H e l l o Space W o r l D

No one really touches or manipulates this translation process, its age old and rock solid. It’s called the atomic structure of information.


Why ones and zeroes? Cause it’s the simplest way to communicate. Like the name says, it’s binary, yes or no, true or false. You start from there and add it up to something complex.

Sending Data as Electricity

Once you convert that text into ones and zeroes, you have essentially converted it onto the smallest piece of information, called a “bit”. Before we talk about electricity think about Morse Code. One Beep, Two Beeps, One Beep in a given period is the way one party conveys a sequence of taps to another, who then rebuilds it into a message. With that in mind, you do the same for electrical communication, using transistors.

Electronic devices like your PC has something called a transistor, which are silicon semi-conductors (does not conduct but feels electricity). These transistors can send/read electrical pulses or signals. So with the morse code example in mind,  that “Hello World” text is converted into ones and zeroes and instead of taps, pulses are sent over an electrical cable to the receiving party which listens for a given period and then creates the Hello World message on the other end.


Images and Music

Ever bought a TV and they say the resolution is 4000 pixels or remember setting the resolution on your desktop PC to 800 by 600? That’s the number of pixels on the screen, little dots that make up the image you are viewing. Each of these dots has a color specification typically a combination of red, green and blue (RBG) example; Red 217, Green 60, Blue 172.


That color code for each pixel is converted into binary, and sent just like the Hello World text. Even sound, which are essentially waveforms which have numerical representations and can be converted into binary too.

With more transistors, you can send a lot more bits at a time, with 8 you can send 8 bits (1 byte) which can represent a binary sequence of numbers up to 255, with 32 it becomes 4.2 billion. Note that 1000 bytes make a kilobyte, 1024 kilobytes make a megabyte. If a song is 3 megabytes, that makes 24 million bits that need to be transferred.

To get this song in 3 seconds, machines need to send each other 8 million bits per second over an agreed period of time so that one is listening while the other sends. That’s where bitrate comes into the picture, and this 3 megabyte song is transferred at a rate of 8mbps (8 million bits per second).

How is Data Sent Over Light

The LAN cables carrying this data between your PC and a router is great for a short distance, but if you’re sending data from Singapore to Germany, it needs to be way faster. This is where light comes in to the picture, specifically Fiber Optic cables. Check out this article on submarine cables.

Fibre Optic cables are essentially highly reflective cables, mirror-like, which you can send a light beam through and it bounces about the cable before reaching the other end. When you send a beam of light, what you are doing is sending a signal that is binary, its 1 or 0, light or dark. The logic is the same, the other party listens, builds that data and it becomes easily readable. And in a single cable, you can send several different beams which bounce around the cable and comes out the other end.

So that, at a very high level, describes how data is sent over cables (electrical and optical). It is the same for wireless, the binary data is converted into radio waves and beamed out to a router, which then does the digital translation, and sends the data the cable way to the router the other end which then converts the signal into radio wave, wirelessly to you.

Wiring – Internet from the Sea

There is a book out there, which costs ~800 dollars, called: The History of Electric Wires and Cables (History of Technology Series) 1St Edition Edition by R.M. Black (Author)

Salute Mr or Ms Black…

It was written in ‘83, and I wonder how thing have changed since then and what  the author would have written about the wired world today. Imagine 1983 with clean desks, pens, notepads, carbon paper…  think 2003, every desk with a desktop PC… and  then 2013 hot desk offices, everything wireless…

Where did this all start?

Submarine Cables

 I love this site ( shows you all the submarine communication cables, these are cables on the sea floor. Think there are a couple of wires down there? Check this out:

Submarine Cable Map


Sea floor cables stretch back to 1851 when the English Channel Submarine Telegraph Company laid the first water-resistant thermoplastic coated line across the English Channel. 46 kilometers long, going from the English South East to France, enabling telegraphic communication between these 2 countries on 15 October.

These cables are the network, the internet. Owned by different companies and governments, information transmission is huge business. There is an awesome article on Mentalfloss that talks about the challenges faced such as sharks (attracted to electromagnetic pulse) trying to eat these cables, ship anchors falling right onto the cable, and spies and saboteurs.

These huge cables head to “cable landing points” where they are powered on to final land based infrastructure. Several major cables terminate at Changi, Singapore (PANC, TIICSC, EAC-C2C). Often enough, many cable projects are skipping landing points and going straight to Data Centers.

So What Happens Next?

The cables break up into many smaller fiber optic lines that run about 100 kilometers at a time, at least 3 feet underground (but typically much deeper) and hits “termination points”.  For example the little fiber point in your home where your router is plugged into for home WiFi, or for buildings it typically ends at a Main Distribution Frame room, where the cables break out further and travel to Wireless Access Points giving out that office WiFi signal or, they land on desks as LAN cables you’d traditionally plug into your laptop.

And that is how the internet travels to you.


Transborder Data Flow Isn’t Free Flowing

Transborder Data Flow

One of the most interesting concepts I learnt recently… the regulations around data flowing from one country to another. Whenever (Transborder Data Flow) TDF is referenced, it is almost certain to mention the European Union laws (EU data protection directive).

It centers around different standards in data privacy. For example the EU laws ensure that any data controller must have technical and organizational measures in place to meet individual privacy objectives. In summary, you have to get consent if you’re collecting personally identifiable data (think date of birth, social security number, even fingerprint) and be transparent about what you are going to do with it, and if the subjects wish to opt-out, they have that right.

What happens if you don’t comply – you could get a warning, get audited, or corporations could face fines of €10 million or more.

So if you have a global cloud based system with infrastructure in North America and Asia, and European customers who use your service… what does all this mean?

You can store data overseas, it is not a question of storage as much as what you do with the data. It gets more complicated when you consider trust domains and using federations or 3rd party identity management, but simply everyone in the mix needs to comply with the data privacy rules in the not just the spirit but in the words of the directive; to collect only the required data not something you need for future use, if you plan to share it with a marketing affiliate it needs to be known to the subject – they have to agree and must be able to update their data, delete if they want. The data must be protected at all times. All parties that use the data must be disclosed, including the purpose.

US-EU Safe Harbor Privacy Shield

An example of transborder data flow as a concept in practice is the privacy shield between the European Union (EU) and the United States, which basically allows organisations in the two continents to transfer data between each other. The European General Data Protection Regulation (GDPR) is more stringent that the American requirements in terms of data privacy. The shield itself has 7 principles which participating organisations must adhere to (pretty much what is described in the section above). So for this shield to work, companies need to make a self-certifying submission that they meet the EU privacy standards, and pay a fee.

What does this mean for Brexit?

If the UK separates from the EU without an agreement, then data transfers from the UK to the EU and vice versa will no longer be considered as compliant to the EU standards. Which means EU companies could be subject to fines if they transfer personally identifiable data of EU citizens to the UK.



Enabling Change Management 2.0

1. Emerging Operational Approaches


Agile & Scrum SRE
Agile is a software development approach, which breaks development work into small increments to minimize on up-front planning and design.


Scrum is an Agile framework.  It is designed for small developer teams to break their work into actions that can be completed within time-boxed iterations, called sprints. Agile works very well in projects where more is unknown than known and partners very closely with the customer at every stage of development.


Site Reliability Engineering is a discipline that incorporates Software Engineering and Systems Automation to solve operations problems. It aims to create highly available, and reliable systems that scale easily and strikes a balance between operations and innovation (to minimize toil).


Its principles are: eliminate toil (manual, low-value tasks), set SLAs, align risk tolerance, and monitor. Best practices in this domain use automation to accomplish progressive rollouts, problem detection and rollback.

DevOps Infrastructure & Platform as a Service
DevOps is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops).


The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.


A key goal for DevOps teams is the establishment of a high cadence of trusted, incremental production releases.

Infrastructure as a Service is fundamentally a concept to provide high-level APIs to reference physical computing resources, location, data partitioning, scaling, security and backup. In a sense, pull hardware through software.


Combined with Platform as a Service, the work of managing hardware is abstracted. Developers are given an “environment” in which the operating system and server software, as well as the underlying server hardware and network infrastructure are taken care of, leaving them free to focus on the business side of scalability, and the application development of their product or service.

With reference to the above listed approaches, it is clear that development is trending towards a modular and quick-deploy style where even hardware is “software-managed”. While there will still be a need for classic waterfall deployments, it is expected to be fewer. As such, whether an organization adopts Agile, DevOps and/or SRE, we can expect the impact to change management is a surge in the volume of changes, requiring speedy turnaround to accommodate scaling business needs, while doing its part to ensure resiliency.


2. Cultural Impact to Change Management

We can predict some changes to the operating culture that stem from the emerging approaches:

Operational Culture Change Impact to Change Management
Development teams will become modular Teams will structure themselves to cater for modular work. Leadership and development will be delegated closer to development enabling agility. This will result in quicker deployment, resulting in an increase in the number of change owners/sponsors
The risk level of all changes would drop Changes stemming from modular work with small scale low risk impact, may not even qualify for the Change Advisory Board review
Wide-participation meetings will fade, deployments will be assumed to be known Through an increase in the number of change owners and changes, it is expected that intra-department meetings will replace inter-department meetings, Change Advisory Boards will be considered redundant and memos/tables in email would be the way to communicate each team’s work to the department, and one department’s work to the next
An acceptance of failure; to fail small and fast To meet the demands on speed, a level of comfort with failing (albeit small and fast) will grow, probably governed by metrics and corresponding issue resolution
Assumptions that all deployments are safe With a focus on generating business value through quicker releases, developers will continually enabled to deploy. They will grow an assumption (if not a need), that there is a governance process in place, that handles the conflict management and resiliency assessment function for them, as a service

3. Value of Governance

Present day industry practices a preference of using the waterfall model for changes, and more so for infrastructure changes, because of 3 factors:

  • Impact assessment
  • Pre-implementation conflict management
  • The extent of resourcing needed to be pre-aligned in the event of rollback/issues

Considering the speed in which software releases continue, there will be a continuing need for conflict management, governance and enterprise visibility (operations). This does not become redundant.

  • Even with the growth of over the cloud Infrastructure-As-A-Service (IAAS) models, infrastructure still need to be premised and maintained for the foreseeable future, unless the corporation completely outsources hosting.
  • Breaking change management into independent unit-levels process not only limits ability to standardize or assure quality, it loses end-to-end governance capability to prevent collision. It further erodes the ability to value add for future resiliency, disabling the develop-to-deploy pipeline through observation and advise on chokepoints.

Therefore, the value of change management can be summarized to these key points:

  • End-to-End visibility; plan-to-post implementation
  • Governance; conflict management, resiliency assessment
  • Business Insights; process improvement opportunity areas

4. Perspectives

In the ITIL framework, change management is defined as part of “Service Transition”, transitioning something newly developed. It ensures that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service.

In the past, the waterfall model placed much of the checking and handling upfront. The quicker world ahead requires change to operate as a service to development teams. With the goal of allowing them to focus on development, governance needs to become heavily automated and pulling on resources in an event driven way when issues surface.

Consider the perspectives from management and technology tower leaders, what output do they seek from change management?

Perspective Interest
Management Why did something fail, what’s to stop recurrence?
Is there an interesting trend affecting operations?
Forecast of activity with high impact or probability of failure
Tower Lead Are there other tasks that conflict with our plan?
Any process change we need to know about?
How are we performing compared to other towers?

5. Enabling Change Management 2.0

Considering the perspectives we have reviewed and the cultural change we can anticipate, the change management practice could consider process re-engineering on a few fronts.

Initiative Description
Instant Approval Consider the typical change record, written in its usual technical way: “71019 COBS ACFS VE UN-ENCRYPTION” plastered with a technical plan that explains this with more acronyms.


Change Management Tools-of-Records try to make the change owner explain internal and external impact in layman terms and very often the approvers for a change, approve with little idea themselves, feeling reassured that others have approved it before them.


Moreover, change reports float up to management with a list of approved changes for review, with very rare discussion around the changes (barring a previously failed one or a well know high impact activity).


We should reconsider the value in change approvals systems; identify what fundamentally adds value to the change and what delays. It is possible that we move into a model where changes are approved from the start and only delayed if there is known conflict.

Risk Level Automation The sleeping data we have in our systems – change history, configuration management database, real estate information to name a few – can be energized into insights that adjust our risk ratings for changes.


For example, a low risk change being done at a location that is increasingly reduced in size, with a corresponding reduction in site assets and thereby reduction in redundancy (continuity) could actually be a high risk change for the site if it fails, even if it’s a fairly routine activity.


Most corporations wait for an annual exercise to revisit risk levels, considering the importance of different assets to different sites and users. In this new age, can we really wait, and moreover, are we really enabled to do this exercise manually?

Conflict Management Change Advisory Boards (CAB) have fundamentally been the way corporations de-conflict and prioritize changes for the past couple decades. Changes are submitted, peer reviewed, reviewed by change managers and then entered into a CAB meeting. It is tried, tested and successful.


Let us assume a world where all change records are immediate approved from the time they are submitted. Assume a peer review is the only review done to check that nothing is missed technically. Given the subject matter experts have already stated what their plans are, all that is left in the way is to ensure they aren’t in conflict of another activity. And there are many factors here – business restrictions that prevent changes during a specific window, a site power outage, a separate activity by another tower planned on the same technology asset.


If conflict management could be a triggered model, where a change is only unapproved if there is a conflict, the entire processing pipeline speeds up exponentially.

Predictive Analysis Consider the enormous history of change data we have, can it be used to tell us about the future.


For example, is there an upcoming possibility that changes get deferred because of lack of resources in a given month? In an ever smaller, connected world of globally distributed teams, where a change is planned in one country and executed by a shift-based team in another, it might not be immediately known that there is a general trend for people to be out of office due to official or un-official adhoc public holiday or seasonal weather events.


Intelligent trending can provide insights into our environment beyond our immediate understanding and save on wasted efforts.

Post Implementation In a rapid deployment world, one that accepts a small amount of failure or potential failure, audits become valuable in assessing that the intended actions of a change were done as planned without inadvertent modifications to assets that were not part of the original activity.


There are persistent tools that can be leveraged to audit the technological landscape for any irregularities.


This would be incredibly beneficial for quick identification of inadvertent changes that did not cause incidents but rather a change that gets uncovered downstream, potentially even causing issues in separate activities, without traceability to the original event that made the modification.

6. Scorecard

The journey to change 2.0 is further down the road, to be enabled by emerging technologies. However change management in the current cultural shift should position the service as a contributor of business insights. One that ensures resiliency and pushes for speed in deployment.

A way to enable this is through reframing the service measurement model. It is an old adage that teams focus on what they are measured against. If change management tried a different set of measures, the service could pull insights that drive risk visibility, performance understanding and business insights for the benefit of the larger organization, thereby enabling process improvement efforts. Moreover, a service’s metrics are the proof of its value and to have a front seat in the new age, change must demonstrate the value it can provide to the organization from its end-to-end viewpoint.

Vision Stewards of Speed and Resiliency
Mission Accelerate the governance pipeline

Drive business value from the change management process

Speed Average time spent to raise a change From draft to pending-approval. Provides insights into speed of ITSM users, and usage.
Average time spent to secure change approval From pending-approval to ready-to-implement. Provides insights into speed of ITSM approvers.
Average outage window duration by tower In an agile/SRE climate, it is vital to ensure that towers are not hogging assets for maintenance longer than necessary to ensure maximum uptime.
% of PDPA / non-PDPA? Indicates the ratio between pre-approved, low time consuming changes and regular changes.
Accuracy % fail / success (by technology & incident type) The overall success/failure rate and severity of issues organized by technology tower
Number of accepted first time vs. rejected In an agile/SRE climate, time should not be lost in poor planning or multiple review cycles of the same activity
# Changes rolled back Provides visibility on issues leading to partially completed or totally backed out changes
Resiliency # of unauthorised changes Review of process breaks
% of changes scheduled outside maintenance window A maintenance window is a prescheduled time when a system can be taken off-line for maintenance, outside of it the risk level increases
% of changes that cause incidents Number of implemented changes that have caused incidents, relative to all implemented changes within a certain time-period. Prerequisite for measuring this KPI is that incidents are correlated to changes.
% of incidents caused by changes versus total number of incidents Perspective on change related incident volume in comparison to the wider set of incidents
Trend Total number of changes, by tower, by status, by year Provides visibility on work volume on a year-to-year trend –  # executed successfully, # failed, # rolled-back
Ratio of number of incidents versus number of changes Acceptable failure percentage
Process Time Benchmarked-Change Time Reduction Year-on-year comparison if a benchmark change (e.g. a regular event such as  AIX Frame upgrade) is done faster or slower
Most Deferred Changes Visibility on the roadblocks that prevent changes from being implemented as scheduled
Availability Planned outages due to changes Outage (unavailability) due to implementation of planned changes, relative to the service hours
Unplanned outages due to changes Unplanned means that the outage (or part of the outage) was not planned before implementation of the change.
Configuration Items CI with the most # number of change related incidents Which assets have had the most failed implementations?
CI with the most # of change rollbacks
Most touched CIs CI with most number of associated changes. Provides visibility on critical assets and insights into protecting them.
Site Site with the most # number of change related incidents Which sites have had the most failed implementations?
Site with the most # of change rollbacks
Most touched Site Site with highest change volume. Provides visibility on the organization’s busiest (and inherently important) sites.
Technology # of failed changes by technology Advises which technology area has not been as successful as others
# of rolled-back changes by technology
Process # Number & type of emergency changes Trends in emergency changes
# of backlogged changes (by technology) Change backlog
Same change, repeated fail (rollback and incident) Changes that were not successful on multiple occasions
% of time coordinating changes Percentage of time (in labor hours) used to coordinate changes relative to all time used to implement (and coordinate) changes.
Audit # of audited changes (pass/fail ) Changes that are inspected based on a weekly random selection or via Evolven to ensure accuracy in CI/Time information between change record and actual implementation


How to Secure Buy-In… How to Sell “it”?


If ever there was an uphill task, it’s getting buy-in – convincing someone to buy whatever you’re selling.

It’s no wonder there are hundreds of books written on this topic. Most of them from the perspective of a business trying to make a deal. What about in a corporation? It’s not like you can knock on the CEO’s door and be granted an audience right away.

If you’re in a corporation trying to sell an idea/solution to your corporate – most of the time the immediate next steps are not clear. Very often you can end up going in circles. So if you had something to propose, how should you go about it?

I’m going to share a real example, how we launched an events management service, and we’ll build this handy little table as we go along, this checklist will help you structure and quantify your idea. This quick survey will help you decide if its worth pursuing.

Questions Yes/No
Is there clear business value
I know how this will be paid for
I know who is willing to pay for this
The numbers make sense, my management will agree
I can do a proof of concept, to secure buy-in
I can get customer supporters to present this idea to decision makers

Business Value

First and foremost, it stats with a need. Don’t think of it as looking at a gap, think of it as “what makes life easier?” Many times you’d know this just by keeping your fingers on the pulse and listening…. It can be the smallest gripes. In our case we heard them say – “its such a waste of time to talk to Vendor X, Vendor Y and Vendor Z to prepare for a townhall…” Just so happens those were IT vendors mentioned and we had super integrator skillsets available.

Business Value is abit more than someone crying for help. Most companies won’t care if an employee has to do more within the day, they are already paying for that employee. So an argument like “not good use of their time” or “not the right skillset” – these in itself won’t hold water.

We looked at the number of events and townhalls the customer had in a year, and reviewed their process – the number of vendors to talk to in preparation for the webcast and audio quality, as well as the type of things that went wrong during the townhall.

Our articulation was like this:

Each year in Asia, you hold 20 mini and major townhall events. These events vary in size, but typically have 100-250 participants joining in person and virtually. These events touch the end user in very direct way, every IT outage is strongly felt as a massive disruption (as we noted in the very last event) and discredits the capability of the IT organization.

 It typically takes your current team weeks to prepare for each townhall, in planning dry runs, and bringing 4 different technology vendors together. Because your resources are not dedicated to running events management as a service, the users face rescheduling/cancelling if schedules don’t align.

 We’re recommending to let us run this service for you. We have onsite presence in all the markets you have been conducting townhalls, and by virtue of this can offer:

  1. A competitive pricing model
  2. Guaranteed availability in accordance to the requester’s schedule
  3. All technical planning and integration to make each event a success
  4. Seamless partnership with your facilities team

Engagement Model

You have to ask yourself:

  • Who would pay for this?
  • How would they pay for this?
  • Is this a one-time service, is it ongoing?

Every company has its own financial process, different ways in which they can pay vendors – service requests, statements-of-work, books-of-work, small-purchase procurement systems.

Make the effort to understand their payment processes and lead times. You’re banging your head against the wall if you find that your customer’s procurement lead time is 1 week but the turnaround time for requests is 3 days. However you package your solution, it has to be realistic – it’s no longer a world where you let customer worry about payment, smart partner should advise the customer on this – which engagement process best fits the service/solution you are proposing.

It’s never wise strategy to package your proposal with a huge single price tag. Most customers today are going to want to see you in action before committing to a longer term agreement. Pay-as-you-use is also becoming a preferred model as the trend of services being commoditized grows.

This is typically where you’d run into a challenge, and where a lot of the works needs to go – packaging your idea into an affordable solution.

In our case, we found that the customer had a generic service request process with a lead time of 1.5 weeks and a cap of 2000 USD – specifically for routine tasks, and best of all, anyone could raise a generic service request.

So we did our math, worked out a task list, calculated the effort, put on the margins and we could offer the customer a per event price that was within the generic service request guidelines. We spoke to the customer’s procurement team to align on the general scope of work – thus making it a service request.

We added this to our business value summary:

Given this service will be used widely, by various business units – we believe that it makes fiscal sense for the business units to pay for the service versus the shared services organization. This would mean that our engagement model for the service must be flexible to allow for different cost-centers and location-codes, and it must have a fairly consistent pricing model.


All the business value in the world won’t matter if the decision makers don’t agree. You could talk an idea to death with the folks whose lives become easier if implemented. What you need to do is ensure that the folks who matter, review it early.

Let’s say we’re told that we need to bring this idea to the regional CIO, you have to real clear in articulating the whole idea in a way that makes sense – what’s the benefit and what’s it going to cost? It may also make sense to lobby some of the folks in the CIO’s organization who stand to benefit from it, to get behind your proposal.

We did 3 things. Firstly, we spoke to the other vendors that supported different parts of a Townhall and socialized what we would do, to see if they welcomed the partnership… Second, we spoke to someone form the customer end who did some level of events management as a secondary role and lobbied for some support on our proposal… Third we reached management on our end, and achieved an internal alignment to do 2 for free to showcase the service.

We added this to the business justification:

As your strategic IT partner, no one knows better than us the value of standardization and producing a consistent level of customer satisfaction in every transaction we engage. We have partnered with your facilities organization and Townhall management team to standardized the pre-event, during-event and post-events IT tasks we conduct such that we are able to offer the service as a general service request in line with corporate standards.

 We are proposing to support this business need with a long term view in mind, we will support 2 events of your choosing for as our investment in this service to prove its value.

The Presentation

If you made it this far, you’re now presenting the proposal to customer leadership.

Not a lot to say in this section, keep it simple J My recommendation on the format:

  1. Start with what you want – the objective/solution
  2. Explain briefly what need it caters for, who benefits
  3. Share costs and what you will do for free

Also think very carefully about the help you need. Was there some signoff that was needed, was there some approval? Do you need a customer point-of-contact to work with on an ongoing basis?


If it takes off, congratulations on the sale. I’d recommend not to stop in a country or a region.

Use the opportunity to grow your profile, do a sharing with your counterparts in other regions.

Once you’ve trended the service for a while, do a management up, share the success with them.

The Summary We Sent

Each year in Asia, <company name> coordinates 20 mini and major townhall events. These events vary in size, but typically have 100-250 participants joining in person and virtually. These events touch the end user in very direct way, every IT outage is felt as a massive disruption (as we noted in the very last event) and discredits the capability of the IT organization.

 It typically takes <department name> approximately 16 hours over 3 weeks to prepare for each event; in planning dry runs, and bringing 4 different technology vendors together. Because your resources are not dedicated to running events management as a service, the users face rescheduling/cancelling if schedules don’t align or worse – they proceed with the event unprepared.

 We’re recommending to let us manage the IT aspect of your events. We have onsite presence in all the markets you have been conducting townhalls, and by virtue of this – we can offer:

  1. A competitive pricing model
  2. Guaranteed availability in accordance to the requester’s schedule
  3. All technical planning and integration to make each event a success
  4. Seamless partnership with your facilities team
  5. Delivery in accordance to your operational standards

 Given this service will be used widely, by various business units – we believe that it makes fiscal sense for the business units to pay for the service versus the shared services organization.

 As your strategic IT partner, no one knows better than us the value of standardization and producing a consistent level of customer satisfaction in every transaction we engage. We have partnered with your facilities organization and Townhall management team to standardized the pre-event, during-event and post-events IT tasks we conduct such that we are able to offer the service as a general service request, in line with corporate standards. This also means our engagement model for the service is flexible to allow for different cost-centers and location-codes with a fairly consistent pricing model.

 We are proposing to commoditize IT support for your events with a long term view in mind. To showcase the value we can bring, we will support 2 events of your choosing for as our investment to prove the value of this proposition.

Operational Risk Management

Operational Risks

Its all about controlling the probability that something goes wrong.

It is one of those topics that people generally don’t like to think about, because it usually means a lot more work on top of the work you already have, or worse – it associates blame for the gap with the person who raised the gap.

What I have come to find is that when it comes to risk management, its probably one of the best areas to look into, to profile yourself as a thought leader.  Like anything else, it is all in the presentation.

Countless times in my careers I have seen people create an urgent and wide attention on “things that need to be fixed right away”, things that have been open for years. And those that do fix it, well they do get rewarded or at least recognized for the effort.

From a value creation perspective, which I define it as your ability to do something more than your regular 9 to 5, what more value are providing – risks are infact generally easier to identify and work on than ideas. Ideas generally require already thinking about a better process or way.

In a risk containment approach – really what you need to do is follow 4 simple steps (and a possible 5th):

  1. Ask, Find, Hunt

If you already are a subject matter expert, then you’d know where to look and you can skip this section.

If you want to profile yourself as a risk management guru, you need to get talk to people – preferably process owners. Look for a few common themes:

    • Process that is manual, and people dependent e.g. someone needs to key everything manually into Excel
    • A role that has no coverage, e.g. if someone is out of office – it’s a scramble, perhaps after hours support is needed at times but no one is ever on-call formally
    • Ask people about past outages, folks tend to remember this – you might strike gold if you meet someone who took the initiative to solve that outage that one time… perhaps you could implement a permanent fix

If you’re already planning to have a value creation sharepoint for your organization, this process becomes easier <see innovation topic>.

  1. Categorize
IMPACT High Impact

Low Probability

High Impact

High Probability

Low Impact

Low Probability

Low Impact

High Probability


The chart is pretty much self-explanatory, all you need to do is to populate it with different risk topics.  Don’t rule out anything yet, put them all in.

Obviously the high impact, high probability risks are the best ones to tackle – typically these would already be addressed in some makeshift fashion or, they are usually too expensive or complicated to fix.


I like the high impact low probability ones – you could smartly group a few together to make a risk bucket, thereby increasing the total probability accordingly. Take the example below, of a typical bakery or confectionery, where the high impact but low probability items could be looked at together and addressed as a Business Continuity Plan.

IMPACT  High Impact / Low Probability

·         Fridge malfunction

·         Printer malfunction

·         Delivery vehicle faulty

 High Impact / High Probability

·         No delivery agent available for after-hours call

 Low Impact / Low Probability

·         Design PC not working

·         Stove no working

 Low Impact / High Probability

·         Fridge condenser gets frozen




  1. Fixing It

Now this is where it gets exciting, what could be done to mitigate the risks?

Chances are the folks that highlighted the risks already have suggestions, but do brainstorm a bit more. If you just happen to have a position with a wider view of the larger organization, you may even be able to find a solution sitting in another department, or a process that could be reused.

Again – talk to people, read, research. The key word here, is business impact. If you cannot identify, qualify or best of all – quantify – any business impact from the risk, it just won’t sell.

If you find that some of the risks you identified are just going to cost too much, or you don’t have an idea on how to fix it – don’t worry, it is still worth highlighting in the form of a “self-study” document, a very short summary work-in-progress write up.

So net – you don’t need a fully cooked solution, but your business case for why this risk matters has to be great. One way to get perspective on this, ask yourself what your management has been talking about, what are the buzzwords and try to relate them… cost savings, productivity improvement, process outages, infrastructure resiliency, impact to billing or shipping processes?

Risk Description
Title/Keyword After Hours Rota <Your Name> <Today’s Date >
One Line Problem Statement XYZ Confectionary is missing / not processing after hour orders on time leading to missed revenue.
Business Value XYZ Confectionary has seen a surge of overnight confectionary orders since launching our online portal. These late orders are priced at a premium, where one after-hours order would equal 3 business hour ones.


We have missed 2 orders in the past month valued at $1,250. We were late in delivery for 8 orders valued at $5,500 leading to customer dissatisfaction.

Recommendation It is recommended a staff Rota is established so that different people are scheduled to be on call on different nights, getting the next day off.
  1. Growing the Program

If this all gets received well by management and you find yourself needing to structure and expand your risk identification pursuit to the rest of your organization, you aren’t going to need to do a lot more than ensure 1) accessibility 2) promotion 3) continuance/wrap-up


I’d recommend to transfer your data to a sharepoint or corporate website, and be sure to define a data gathering structure that makes it easy for you to pick out the ones with big potential or to be able to pull data in an organized way.

At the very least you need to have a short summary, business value, recommendation and impact. But also consider, if you are in a confectionary for example and you have 5-6 key workstreams, e.g. baking, delivery, storage, packing, sales, others – you may want to force folks to pick which of these areas the risks fall in. It can give insights into tackling a couple of strategic risk areas.


You could sell the idea of how a collectively team identifying risks, to be mitigated, helps everyone and is a virtuous pursuit – but I can safely tell you nothing draws interest as much as a rewarded effort. Try to secure a something simple from management, dinner or a cash prize for the person or team that comes up with the best risk, and mitigates it every quarter.

It would also help indeed if you spoke to department heads, or joined several department team meetings to spend 10 minutes asking about the risk mitigation program. Nothing works  better to illustrate what you are seeking than to do a quick demo, and show a real example.


The easier it is for people to use the portal you setup, the more successful it will be. That said, try not to allow risks to be registered without a concluding status. Commonly you’d ask people to pick from these 4 – Avoid, Accept, Mitigate or Transfer, where:

    • Avoid – you actually plug the gap, fix it!
    • Accept – there are risks so small and at times on non-value adding process, that everyone just signs off and accepts the risk
    • Mitigate – you put a workaround that reduces the likelihood significantly
    • Transfer – outsource the risk for someone else to bridge the gap

If these sound too difficult to explain in a 10minute briefing – I’d recommend keeping it as Open/Close/Keep-In-View where:

    • Open – we’re still working on how to mitigate the risk
    • Accepted – we accepted it, can’t fix it
    • Fixed – implemented a fix

Once you feel that you’ve run the program for a good stretch, its really important to showcase your value as a program leader, and this is where having structured the data gathering bit will be useful. Present to management a report on insights, a 2-slide summary if you will. Organise the data into logical buckets and share interesting considerations.

  1. Other relevant data

In closing, it is absolutely true that a good grassroots risk mitigation program can save a lot of downstream outages and waste in manpower spent in solving a known problem. However there isn’t any real metric to quantify success for a risk program, unlike a sales program which takes the total numeric growth as win – you can’t say a surge in registered risks is a good thing.

Its also difficult and somewhat demoralizing everyone spends their time only thinking about what could go wrong instead of what can go right – new processes and technology vs trying to fix existing outdated ones. Its not a culture folks would want to embrace.

My recommendation would be to do an annual exercise, the risk review – or something of this nature. A month in a year, with a small prize, I think you’d get a lot done quite quickly.

If you’re super interested in this topic, I’d recommend that you read: Blowup (Awesome article about risk in Malcolm Gladwell’s book What the Dog Saw… ) Posted January 22, 1996 by MALCOLM GLADWELL & filed under DEPT. OF DISPUTATION, THE NEW YORKER – ARCHIVE.

How to manage a project without project management training?

How to manage a project without project management training?

A recurring and strange theme in my career has been project management. Many times I have been asked to lead projects, of all sizes… small service launches to multi-million dollar multi-vendor pursuits. I never really had any project management training other than a module in my software engineering degree, yet I think I was pretty successful in getting the job done, albeit imperfectly.

This article came to life as I was in a team meeting, I had asked a team member to lead a small project and he said he didn’t have the right training… I quipped “why would you need to be trained on something you are perfectly capable of doing already…” Of course he was after the esteemed PMP certification… and why not, if he is to do a function for a corporation why not achieve the right credentials, and while I do have my gripe on how corporations often fall short in getting their resources certified – it’s a separate topic altogether. What happened next was we carried on the mtg over lunch and the team asked how I managed projects, without project management training?

First off, lets define “project”… if I gave my kid 5 dollars and told him to buy an apple from the store and he had the option of taking the bus or train, and had to come back in an hour – a successful project would require him to pick his resources, do it within a budget and come back with my bloody apple. Anything short is a failed project.

Of course let’s also be clear that I am not talking about building the national highway system, but that’s the point I was making to the team – project management isn’t that hard if you focus on a few key things, and hold a few principles closely. So how does someone without project management training manage a project… that’s what we talked about in 45 mins over lunch, and I am going to re-create here as best I can remember:

Step 0: Charm School

More than anything else, a project is a team effort, strong relationships is the key. As much as you want to define Roles and Responsibilities, it’s never going to be perfect and you never know where you are going to need help… and not everything can be a change request… so don’t be a fiery dick! Be nice, connect often. Take an interest in how everyone else is doing, cause inadvertently or not – everyone else’s schedule could affect you.

Don’t escalate blindly, get overly aggressive and think that it’s a winning formula to frighten everyone to work… it may work for a bullshit little project but when you get to the big stuff, you really want to work with. So, be nice.

Step 1: What’s the deliverable?

A contract will typically define a cube as 6 connected squares. Your customer may define it as a steel box of 6 sides with 6 different colors that glows in the dark. It’s really important to identify what success looks like in the eyes of your customer.

Sometimes in the simplest projects – it’s unwritten. There was a customer who told me that he had no time for the project he was assigned, all he needed was a monthly report showing progress that he could take to his management, and that I work with all the other vendors independently – I asked for a template he wanted to see the information in, and to introduce us to the other vendors… realizing I’d be spending a fair bit of time in meetings and I needed someone to build a fancy report every month, I added the effort into the contract so that it’s billable and bingo, project was a breeze.

Never work with half-baked requirements, even if you get scolded 10 times trying to collect it… you have to literally taste what the end product needs to be before you start any work! I remember spending over a month in 8 mtgs with a customer who kept trying to explain what she wanted, each time we met I brought all sorts of pictures/templates/past-examples… until we finally struck a chord… I then sent a 3 page email with explicit details on what I would be delivering and pressured her for another 2 weeks to acknowledge. I got escalated to my management for being “inflexible” J Better inflexible in requirements gathering than incompetent when the product turns out wrong.

Step 2: Who’s it for?

Stakeholders: who influences everyone, who’s voice counts, who signs off, who can make things happen. People talk about communication plan, a smart project manager makes an engagement plan – weekly tea with X, weekly beer with Y, weekly lunch with Z, weekly emails to A,B,C.

Chances are you have your contracted scope-of-work which was informed to you by a customer leader, who’s part of a small team that’s similarly engaged other vendors with the hope that all of you work together to make it a success with little intervention on their part. Knowing who to work with, and how to work with them is vital. Everyone’s got touchpoints and everyone is lobbying the customer to believe that they have everything ready – it’s everyone else that’s slow.

Keeping your head buried in your project plan, turning up only when there is a committee meeting, isn’t wise. Build the right relationships early, keep them engaged throughout.

Step 3: When is it due?

Knowing what you need to deliver, to who, and how they want it – helps you identify your resourcing and financial needs, which is completed with one more detail – when you do you need to deliver all of it.

Anyone who has hired an interior designer (ID) in Singapore will tell you that time is an illusion to the average ID, they plan a project with a slack in their heads of several weeks assuming it’s an accepted norm. Very often they don’t get return business, their reputation goes down the drain and they open a new company with a new name and start over. The key reasons for this 1) they collect and try to work with half-baked requirements, making an effort to understand as they go along 2) their don’t understand the concept of dependencies and never do plan to complete ahead of schedule

Never plan a project to miss a deadline. I’d recommend have 2 project plans, one which is reported and one with dependencies only for you to track. It is easy to get lost in the details, if you have a thousand line excel plan I bet everyone has seen and discussed it again and again and again are bored stiff, but that’s for the people working on your set schedule to know what they need to do and by when – what about the external influences?

As the person-in-charge, you need to identify those key “needs” and “risks”. For example, if you were going to build a server room, chances are you’d have your orders placed, all those backend teams ready to support the move, all your onsite people ready to setup onsite… but… those construction guys, what do they need to provide –

What When If Missed Mitigation
The room needs to be ready for us to start moving in 1 Mar Need alternative storage Communicate to construction team, room is needed by 1 Mar with power and electricity. Our deadline is 7 Mar. If 1 Mar is missed, get a drop-dead date and let customers know if we will be late as a result.
Power needs to be turned on 7 Mar Setup is delayed
Air Conditioning needs to be ready 7 Mar Setup is delayed
Connectivity needs to be ready 7 Mar Setup is delayed

Smart managers think ahead, plan early, and communicate new recommendations quickly.

People think of escalation as a bad thing, it is part of the bureaucracy – its way to get attention on a risk and help to move ahead. I’d recommend doing a joint mtg and escalating the concern jointly from the mtg, instead of you highlighting and condemning the rest.

 Step 4: Your resources, people and tools and money… and my project plan!

Chances are you figured I’d be writing the most in this section… but strangely, unless you are in business for yourself and working on your own project – this part is quite straightforward. There is a super high chance, that there is already a project management organization who has set the standards in reporting and processes to get resourcing, finances etc. So then it becomes a function of reading and learning.

My advise – learn from past implementations. Ask them for a couple of similar projects successfully completed before, share with you the project plan and connect you with the project manager and ask these 3 magic questions:

  1. How do I start?
  2. What were the challenges you faced?
  3. Any learnings you can share?

And really if you think about it, the challenge is not a lot more if your company doesn’t have a PMO, you just need to find the folks who done it before and grab advise to get you off the ground.

If you can, try to find someone who’s delivered the project you’re working on before. Keep this fellow handy, you may need to go back time and again for advise to circumvent issues.

Most importantly – the plan. Nothing beats having a completed project’s plan as a reference point. Believe me, building a project plan piece by piece is a great way to learn everything, but its all so much smoother and faster if you had reference material.

If you really don’t have a plan that you can reference, I’d recommend to just break the project into many small categories and start talking to people about each one, to get an idea on what/who/how/when… you wont have all the answers but it will give you enough detail to put together a high level plan… 

Thoughts What Who How When
Servers Wintel, networking devices List of server owners – ask Mike

List of N/W devices – ask Bryan

Servers are cabled first, then built, OS… 4 hrs Facility needs to have raised floor, power, aircon, connectivity
Applications Application List Apps owners, ask John Can be done remotely Apps go in after DB…
Databases Oracle team Alex Can be done remotely DB is put in after the server is built..

Step 5: The Short/Mid/Long Term

The Short Term

Solidify – your goal in the short term should be to elicit clear requirements, build a solid plan, socialize.

This is the best phase to build relationships, when everything is still moving smoothly.  Reporting is key – always send out progress updates to demonstrate you are on top of things.

The Mid Term

Calibration – the requirements may change, some of your dependencies may not be ready, you may face schedule and budget overruns. Always pre-empt the stuff that can go wrong, and what you need to do about it. Run through your project plan with your team again and again, new considerations will pop out, talk to the other vendors – catch the hint of a miss early. Protect your interest, don’t just let the world happen to you.

The Long Term

Commercialize – through every project you build a reputation, it does matter what people say and it does matter that people want to acknowledge your work. Sure there will be disagreements, misses and issues to deal with, whether its peaceful and deal with together – depends on you. At the end of your project, how much of a success it is, depends on how its articulated. I’d imagine that a 2-page journey summary, with photographs, positive comments from the vendors you partnered with, good feedback from your customer (throughout the project) – would be a lot more impactful to your management, a better showcase of your collaborative talent than just “ok, done, what’s next”.

How to Create an Innovation Program

Innovation – the destination doesn’t decide the journey…

Marriam Webster says this is the act or process of introducing new ideas, devices, or methods.

And yet in an organization, when you’re far away from R&D and working in pretty regulated department, you aren’t really empowered to make change. You feel that a lot of things need to happen, a lot of people need to buy-in to the “act or process”, when they actually only give buy-in when they see “new ideas, devices, or methods”.

Ever heard folks say: “Its so simple, they just need to do it that way”… “if it was left to me, I would do this this/that/the other way”…

This isn’t uncommon and you are right, those breakthrough ideas you read about – had a lot of backing and sponsorship which you aren’t typically going to get.

But you want to tick-off “innovation” as an item on your resume, maybe it will help you land the next job, maybe it will help you look good in front of your manager. However it helps you, this article is going give you the means to start a small, no-cost innovation program – where you can sell the “act or process”, instead of the “new ideas, devices, or methods”.

Step 1: Time It

Plan it according to your appraisal, this shouldn’t take more than 6 months, so start a couple months after your goal setting discussion with your manager and end a couple months before the end of year conversation – so that its fresh in the minds of everyone.

Step 2: Begin With the End in Mind

Now this is where the real thinking comes in. You need to have an inkling about the low hanging fruit – what can be fixed not how and bridge it to a manager who stands to gain from this. That’s your business case. Let me give you a couple real examples:

The Small Department

There was once a plain old department that handled some excel work. They didn’t manage any big systems or applications or processes. But they still were a department with HR processes – leave, reimbursement and the excel work they did. One bright spark put all 3 of those into a bucket called “operational innovation”, and made small improvements such as skipping redundant steps in the HR processes and made macros to automate some of the excel work.

The Large Division

I happen to work with a larger corporation, numbering about 150 folks. What I did was:

  1. Fixed something small myself. Presented the small win to Management in dollar savings terms and asked if they would be open to me starting a low-time investment, free-of-charge innovation program… all I needed was a sharepoint webpage and their support when I call for action.
  2. I lobbied several senior team members (amazing how the best ideas always come from the people who execute processes), and pulled a list of improvement ideas. I asked a couple of team members to turn the ideas into process and execute the improvement, and logged the success on the sharepoint.
    Tip: Share the early wins to Management to keep them warm.


  3. With the data on the sharepoint, I had an example to demonstrate the innovation program – I then held a large team meeting and asked everyone to contribute one idea by the end of the month, and each department to log a major operational risk by the end of every quarter.


  4. Every month I chased folks to execute their ideas, every quarter I presented the growing number of ideas to management. By the third quarter I was able to show that there were 50 ideas registered, 10 implemented which generated savings in cost and time.
  5. For the other 40 ideas I grouped them into a few big buckets and recommended that we secure some funding to pursue 3 improvement projects, which became my following year’s value add.

Step 3: Market It with a Bang

Be smart – look for the right avenues to market the work you have done. After a certain point, don’t call it “innovation program”, call it “value creation” – don’t tell folks you are developing ideas and identifying risks, tell them you are sieving out improvement opportunities that are relevant to meeting business goals. Don’t say this idea fixed an internal process, say it saves 10 man hours, don’t say an idea saves 50 dollars a month – say that without it the 2 year cost would have been over a thousand dollars.

Presenting your program with the right data points. You don’t need to say a lot, just say the right things.

Tip: when the well runs dry, and it will – start looking at risk instead of ideas more aggressively