Over the years, I have worked in many project implementation. One of the funniest moment that I can look back and laugh is the wrong buy in of key users. It is not surprising that users are inserted in projects for their titles. Being new to these type of projects, you cannot chase them out until it is too late.
Watch the Signs
The first signs of such users are roles and accountability they played in projects. It is common to find no action items tagged to these users. They usually contribute with opinions like “influencer”. Usually, these users are vocal participants and unlikely to “chair” any meetings. They relish on conflicts and enjoy asking status of anything they can think of. If you encounter these signs in your users, do not invest efforts to buy in their “flavors”.
If your projects have such users, it is wise to avoid confrontations with them. This is because these users thrive with such situations. Lots of noise and unnecessary requests will increase once these users gain a foothold in your projects. Therefore, you must stay true and be focused for your project. A project timeline required focus fo reach its objective.
If you have buy in the wrong users, do not be discouraged. This is because we need go gain experiences to handle such cases. There are user signs you can look for and this will help you stay focus complete for project.
The steady state is an important concept for development and project planning. Agile view it differently with another backlog of change. We should learn how to manage this by considering it in our planning or development.
The development of new features are less constant than existing ones. At this stage, requirements are less clear. Bugs are common and affects the data integrity. A huge scope will require more time to be stable. One strategy is to adopt use case for quicker steady state rather than going for a full suites of product.
The priority is to achieve stability and set a baseline on which you can enhance. Some called it versioning. You can group the changes and manage stability at a steady state. You need to establish measurements for stability. Monitoring and maintenance are part of your processes to achieve stability.
A stable system is at its steady state. Data will be less likely to be affected by timing issues. You should always achieve steady state before embarking on the next change. This requires planning and understanding of the relationships of change and steady state.
A key aspect of working in office is socialising. Of course, these are exceptions for essential workers. Gatherings, coffee breaks and pantries are ways of informal exchange of information. These are often not replaceable by group chat because many of these encounters are as ad hoc in nature. Restricting these exchanges will defeat the purpose of working in office. Literally, it is telling you to be physically in office but socially removed.
Bring your Own Risk
The messages conveyed are confusing to organisation and individuals. If there is no further lockdowns, why are Quarantine Orders (QO) or LOA (Leave of Absence) still being issued? This means risk are in your own hands. Yes, you can go out or work in office. If there is QO or LOA, it is yours to bear. This means that teams should determine the importance level of working in office or risk exposure by blind compliance.
The endemic is shaping the risk and mindset for many of us. This is why guidelines are set instead of rules. We must be allowed to determine our own risk appetite towards COVID-19 at our discretion.
The reality to endemic seems confusing these days in Singapore. After all, trade and borders opening is the priority for the economy. Endemic mindset remains fuzzy as COVID-19 variants persisted. Many questions the rationale of what endemic means. Will we be mask free? Are we going to penalise and segregate vaccinated and non vaccinated?
What is Endemic?
Flu and cold are known illnesses that we taken for granted in a society we called endemic. Will we treat COVID-19 like a common cold? Or will we treated common cold illnesses like COVID-19 in future? When we murked our ways through the endemic or “new normal”, who should get their feet muddy first.
Time to be Clear
This is a time to be firm and decide to be endemic or “new normal”. There will have to a clear line between what will be a rule or guideline. If there is benefit of doubt, it means risk at your own discretion. Will we be penalise for being cautious? For each relaxation, clusters will be normal. An endemic will not consider these clusters as critical. How should we react if these are reported?
The long drawn war with COVID-19 is taking a deep toll with economy and trade. Perhaps this is a time to send a message that we will only need to wear masks if we felt sick. After all, this is how endemic society should be.
Cloud and On premise reminds me of A Tale of Two Cities. One is being replaced gradually without the other having knowledge of it. It is not surprising some teams will remain in self denial of the proliferation of Cloud.
Similarities and Revolution
Cloud is nothing new and have been around for decades like hosted servers or managed services. The revolution comes about in the form of Digital Transformation from need for larger and larger server capacity in a particular entity and virtualisation. Suddenly, everyone jumps to the bandwagon as costs plummets with competition. However, not all teams are challenged to change.
How this Ends?
If you are familiar with the ending of the story, Darnay is knocked unconscious while being replaced by Carton for the guillotine. Does this sounds familiar if you are belonging to the teams who are not on Cloud? In many organisations, this replacement are taking place without involvement of on premise team. In most case, decisions are done at top management level and the teams are only engaged during migration. What a stark reminder to being at the guillotine!
A Tale of Two Cities are playing out at many organisations. However, it is a good suggestion that this should not be the plot. The ending is not pleasant for many. It is time we revisit the playbook and mirror another tale!
Having an oversea sites can run into all sorts of networking issues if you are accessing these websites in China. This is because of the well known firewall of China. You will need alternative solution if you have users in China that use websites outside of China. If no, you will be running into countless uncontrollable risks.
Time to Locate a Mirror in China
Unlike other countries, it is favorable to have a mirror sites in China. You can consider this option if you have a large user base in China. Although there are conditions to setup a website, the returns will outweigh the risks of blocks from China firewall. The mirror site can also serve as your redundancy or CDN (Content Delivery Network) for high availability and added performance.
If you do not meet the conditions for a mirror site in China, there are other options for you to consider. You can transmit your data real time via your VPN instead of the regular internet. Using VPN have its advantages with faster latency. However, there are also risks because they will be subjected to firewall blocks and it will also cost more. You may also consider store and forward method where you accumulate your data for transmission. Although you may not have real time data, you can manage your user expectations and controlled your data transmission at a lower cost and systematic manner.
Having users in China is a tricky approach for your website. If you have a large user base in China, it is worthwhile to invest a mirror site within China. Otherwise, you may consider lowering user expectations and opt for non real-time or less availability solutions.
If you have done many application projects, it is common to find that exceptions are often being provided as a rule by users. This is a key reason for major scope creep when you try to cater to exception. Is exception a rule? Can this be considered as a rule?
Exception is a Process
The first approach to exception handling is educate users that exception is a process to be managed. It is not a rule that system is able to followed. A rule existed from known set of variables. On the other hand, exception represent special scenarios and unknown variants. Thus, this distinguish exception from a being rule.
Exception is Unpredictable
The second key characteristic of exception is the nature of occurrence. It is unpredictable and sporadic. In fact, some exceptions break the established rules. This is where users demand that exception be made as a rule. That exception will conflict with existing rules. If you attempt to fit the exception as a rule, scope creep will occur.
User education is important to distinguish exception from a rule. Exception often break existing rule and must be handled as a process. Usually, users cannot determine the frequency of exception. After all, exception is not a rule!
We had an outages yesterday that was totally unexpected. It was so big that the major news reported them i.e. Akamai outages. It was surprising because we would have thought this type of outages were a relic of the past. How should outages being handled in a world where users cannot tolerate 5 min of downtime?
Formation of Outage Team
Do you have an outage team? It is likely majority of organisations do not have an outage team. Neither are outage drills conducted in large scale for the organisation. You can relate this like a fire drill where you will have a fire drill team for your entire buildings. This team is usually cross functional and well drilled in various skillsets from infrastructure, security and applications. Although this team could be costly, it is worthwhile to note that outages may cost a 100 times more.
Outage management is different from disaster recovery. Disaster recovery usually deals mostly with internal applications or related downtime. These SOP (Standard Operating Procedure) could be formal processes with your external parties. When outage happens in the old ways, it usually starts with a Sev1 (Severity 1) and manage with standard incident management process. It will take an hour or more before this is deem an outage. The slower pace and passive nature of incident management may not suit today’s outage.
Outages are no longer isolated in nature due to Cloud and networked environment. Case study like Akamai outage will lead organisations to consider a need for outage team who are highly trained and focused to manage outages swiftly.
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?
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.
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.
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