STAAH Hotels Software Pvt. Ltd.

Information Technology Department

SWOT Analysis and Recommendations Report
2023
________________________________________________________________________

Neeraj Gupta, Consultant

24/04/2023
Executive Summary of Recommendations
Information technology exists to support the mission of the organization as defined by Company
leadership. Investments in information technology are driven principally by the desire to improve the way
work is done, to improve decision making, to adhere to various laws, regulations, and policies, and to
help the organization manage its risks.

The recommendations in this document serve as the foundation for strategically investing in IT resources
and to facilitate the work of a new IT governance structure for the Staah Hotels Software Pvt. Ltd. This
effort is initiated by Neeraj Gupta upon request from Staah CTO Gavin Jeddo, Head of India Operations
Ravi Chhabria and Staah CEO Tony Howlett.

Neeraj is charged with the responsibility to build on the recommendations and continue to develop IT
governance concepts, vision, principles, and organizational structures.

11 Major IT functional areas were identified after interviewing over 15 product teams, their mentors and
leaders across the organization regarding IT opportunities for improvement:

 Establish IT Governance

 Processes, Environments and Practices

 Code Quality

 QA Practice

 Team

 Downtime SLAs and Disaster Recovery

 Partner Support and Business Team

 Infrastructure, Security, Monitoring and Logging

 Products

 Organization

 Establish a Sustainable IT Cost and Funding Model

Establish IT Governance

The principal stakeholder for this function is the leadership of the company, which has responsibility to
make sure the IT resources of the organizations are properly governed. The Organizational staff depends
on IT services to do its work. Making appropriate investments in IT requires effective decision making on
the part of leadership.

Recommendation Summary
 Develop and implement a process that provides strategic leadership, establishes org ‐wide IT
priorities, and produces accountability and transparency.
 Create a core committee to empower the strategic, operational and technical decision ‐making
required to ensure that IT enables the company to excel in its mission and accomplish the
priorities, goals, and initiatives set forth by organization leadership.
 Ensure that information security and privacy concerns are addressed throughout the governance
process.
 Provide an annual report to the company regarding progress in addressing the gaps in IT
functional areas.

Key Benefits to the company

 Makes IT decision making transparent.
 Establishes small, focused teams charged with specific roles, responsibilities, decision making
and accountability for IT investments.
 Establishes a “big picture” outlook for IT investments.
 Allocates IT resources and sets IT investment priorities that align with Company goals and
objectives.
 Aligns IT plans with other strategic plans of the company.
 Brings Products plans together into a single coherent org wide IT strategy.

Processes, Environments and Practices

Processes, Environments and Practices followed in the IT department are its backbone and should be
analyzed carefully. Robust and proven processes and practices needs to be established as benchmarks for
all divisions and products to follow.

Strengths
1. Development environment is separate and it has its own local DB
2. Credit card transaction process flow is properly encrypted and is secure.
3. ZOHO tool is getting used in some capacity for agile development.
Weaknesses
1. Standard DB and Application environments are not in place.
2. Proper product development and release planning in not in place. At times, people are rushed into
the development cycle without giving them a complete understanding of the whole bigger picture.
Multiple releases happening on same day (sometimes even 50)
3. Requirement gathering: BRDs are not created. Team gets the idea directly from Business team
verbally. Team work on the idea which still has unclear aspects and then when it’s presented,
there is a mismatch in expectations and what is built. This at times, results in rework and impacts
efficiency of the team.
4. Agile development or other proven methodologies are not being used by all Dev teams and it’s
very hard to ascertain how much time is needed for a feature and when it will be delivered.
5. At times, work comes unplanned in an unplanned way and team is expected to change gears
quickly resulting in loss of productivity and quality. Team needs bandwidth to create good
changes.
6. Technical support organization needs improvements. Its kind of missing at this point.
7. Deliveries gets delayed sometimes due to communication issues, cross team coordination and
lack of proper testing

Opportunities
1. Backups should be created in separate region with 15 minutes or 1 hour sync process to avoid
important data loss.
2. Opportunity to follow agile methodology and rapid flexible, development plans
3. A document could be created explaining regular acronyms used across teams for products and in
general like SU, PMS Etc.

Threats
1. UAT environment is using Production RDS DB. Data is very critical and this could lead to
corruption of production data.
2. CVV storage in 'Help for hotels' system is a threat as it’s prohibited.

Recommendations
1. Data is very critical and key part of any application. Security and Sanctity of data needs to be
maintained at top priority. Create separate Database instances to support UAT/Staging and
DEV/QA environments. These environments should not be allowed to use Production DB under
no circumstances.
2. Separate Dev/QA and Staging/UAT environments should be configured for every product.
3. Product teams should follow agile development process. Product requirements should be drafted
using BRDs and converted to user stories which should be pushed to backlog and then planned
for the sprints. User stories should be estimated and story points should be assigned to each story.
A proper product release plan should be created, tracked and delivered. Automated CI/CD
pipelines should be created for deployments. Recommended Tool: JIRA.
4. Change request should be created for every production release and should follow thru the
approval cycle before the release. Only Infra team should handle Production releases. No one else
should have direct access to production environment.
 5. Create a leadership layer between Business team and mentors to make changes and process more
streamlined and planned.
6. A product manager should be added to create delivery plan, run sprints and manage change
requests and delivery schedules for few important products. Mentors should focus on their core
competencies which is technical aspect of the product.
7. Practices which are prohibited by law in different countries (like storing CVV) should be
avoided.
8. Production releases should be avoided on Friday/Saturday night as there’s a high chance that it
may cause issues which need IT team to work and resolve over weekends. Ideally releases should
be planned once every 2 weeks.
9. Partner services should avoid doing any setups near and over the weekends unless absolutely
necessary in order to avoid issues needing IT teams to resolve over weekends.
10. Adhoc task and features should be planned in a more organized way. They should be added to the
stories backlog and then should get prioritized for upcoming sprints. Unplanned shifts in focus
and priorities show that organizations roadmap is not properly planned.
11. Technical support organization should be built using Devops model. People should be assigned to
Support (for Tickets) and development (for new enhancements/features) every sprint and should
be rotated accordingly. 1st, 2nd and 3rd level support should be built.
12. A proper communication plan should be established identifying daily, weekly and monthly
information needs across teams and by product leadership.
13. People should be motivated to focus their minds towards innovation, learning new technologies
and researching on how to make products better.
14. Cross team coordination and communication should be improved. Cross product knowledge
needs to be built within the teams.

Recommendations Execution Plan

1. Work with Product Manager and Mentors to create a plan for establishing separate Dev, QA (or
UAT) and Production environments with their separate Database and deployment pipeline setups.
Priority: High
Actions and Owners:
 Creating and driving over all Plan and tracking Weekly Progress – Neeraj
 Execution and creation of separate environments – Mentors
 Reporting weekly/Monthly progress – Product Manager (Should be hired)
Timelines: 6 - 12 Months
Key Points to Note: This may warrant some additional AWS environment and associated services
resulting in additional costs. Implementation plan and timelines will depend on allocated budget
and approvals. Some part of team bandwidth will be utilized as well which means that delivery
dates for some of the planned deliverables might get impacted.

2. Setup agile development process across products. Product requirements should be drafted using
BRDs. Story creation, sprint planning, Delivery schedule, change requests and release planning
should be setup. Developers should be allowed to do code changes in Dev. Environment only.
Production environment should be handled only by Infra team.
Priority: Medium
Actions and Owners:
 Driving the program and tracking over all Weekly Progress – Neeraj
  BRD creation – Product Manager (should be hired) or Business stakeholder team
(Angie, Cheyenne)
 Story creation and clarify requirements – Product Manager (Should be hired)
 Sprint Planning, execution and reporting – Product Manager
 Ensuring proper test estimations are done and included as part of the final delivery
plan – Product Manager
 Ensuring that developers are not updating code directly in UAT or Production
environment – Mentors.
 Ensuring Production releases are handled by Infra team and no one else has direct
access to production environment - Nitin
Timelines: 6 - 9 Months
Key Points to Note: This may impact some team bandwidth initially as team will need some
adjustment time to new changes. Change requests and release planning will be focused towards
bringing some order to our releases which are happening daily at will. Focus will be to combine
product changes and release during planned 2 week or 4-week cycle.

3. Technical support organization will be established using Devops model. People will be assigned
to Support (for Tickets) and development (for new enhancements/features) every sprint and will
be rotated accordingly. 3rd level support should be built as part of dev-ops team.
Priority: Medium
Actions and Owners:
 Driving the process and tracking over all Weekly Progress – Neeraj
 Aligning Business team and publishing support roaster every sprint – Product
Manager
 Ground level execution ensuring task assignments are effective and productivity is
not impacted – Mentors
Timelines: 4 to 6 Months
Key Points to Note: This may impact some part of team bandwidth initially as team will need
some adjustment time to new changes.

4. A proper communication plan will be established identifying daily, weekly and monthly
information needs across teams and by leadership.
Priority: High
Actions and Owners:
 Work with Leadership and mentors to identify required communications and
reporting needs – Neeraj
 Driving and tracking weekly progress till the time its matured - Neeraj
 Create needed changes in tools (or adapt to new tools) to ensure that proper reporting
data is in place – Chirag and Nitin
 Start sending out agreed communications and reports periodically (daily, weekly,
monthly) – Team, Mentors and Product Managers
Timelines: 3 - 6 Months
Key Points to Note: Timelines will depend upon the changes required in tool currently being used
or team getting acquainted to new tools. Team will need to build a discipline to keep entering the
 correct data in timely manner for the reports to represent correct matrices.

Code Quality

Code is an integral part of any product. Code quality is crucial for developers because poorly written code
can lead to technical debt and security issues. Technical debt refers to the idea that bugs and code
deficiencies can buildup over time to the point where the cost of new code changes becomes much
greater.

Strengths
1. Site is working fine and no major breakages observed.
2. Current code base is holding the site and meeting performance needs to some extent.

Weaknesses
1. Code is written poorly in many areas especially developed by new fresh out of college and less
experienced developers.
2. Technical debt is quite considerable at this point.
3. Appropriate coding standards and guidelines are not being followed. At times developers are
writing code in UAT environment directly.
4. Code reviews are not happening. Team has no idea if the code is secure or not.
5. Tedious code component interdependencies exist. In the absence of clear long term vision and
direction initial product code lacks in important areas like scalability, performance and clean
design. Product code is being rewritten from time to time.
6. Some of the code is still in SVN. AWS Code Commit (GIT) version control is being utilized
poorly. Development, UAT and Production code bases are not in sync. Versions are not being
baseline and maintained.
7. Standard naming conventions are not followed.
8. Few products have code written in Pearl scripts.

Opportunities
1. There are opportunities to reduce the technical debt during enhancements and bug fixes.
2. As the product is growing and so is the code base, opportunities should be identified to make the
code more robust, clean and reliable.
3. Staah code is written in a way that lot of undesirable data transfer is happening across network
causing additional charges by AWS. Initiatives could be taken to identify and reduce this data
transfer.
4. There are opportunities to review caching strategies across products and make changes to achieve
fast response time.

Threats
1. Absence of Standard code review tools and processes makes the site vulnerable to security
attacks/issues, performance bottlenecks and application/system breakdown.
Recommendations
1. Find opportunities during new development, enhancements and bug fixes to reduce the technical
debt and review/refine the code of any one component.
2. Developers should not be allowed to change code directly in UAT or Prod environments. Any
changes they need to do should be done into development environment only.
3. Code review tools such as Checkmarx, Checkpoint or Snyk should be integrated which could
check for code standards quality and security concerns/defects. If these are costly then some cost
effective alternatives should be explored.
4. Cross product manual code review by mentors or senior developers should be introduced to make
code quality robust and address security/performance concerns. Code reviews are essential to
improve engagement across teams and improving code health over time. All review findings
should be documented and evidence of fixes should be produced.
5. Code reviews also provide developers with an opportunity to learn new technology and
techniques and grow their skill set. Idea is to review the code and not the developer.
6. Spend time on Design workshops to create right and clean product design with long term vision
to avoid rewriting and creating similar products again.
7. GIT branching strategies should be used properly and timely code merges should be done to keep
Development, UAT and Production codebase in sync. This should happen across all products.
Release versions should be baseline and maintained.
8. Remaining code from SVN repositories should be migrated to AWS Code Commit.
9. Number of repositories should be reduced. Maximum of 1 repository per product should be there.
10. Developers should follow standard file naming conventions. Code Commit and Merge process is
error prone and needs to be reviewed for improvement.
11. Pearl scripts should be migrated to Python or PHP.
12. Use responsive web design for UI creation so one set of code fits all devices.

Recommendations Execution Plan

1. Code review tools such as Checkmarx, Checkpoint or Snyk should be integrated which could
check for code standards quality and security concerns/defects. This is required for PCI
compliance as well. Cross product code reviews should happen.
Priority: High
Actions and Owners:
 Work with Nitin and Aakash to analyze different tools and recommend the right tool
– Neeraj
 POC with different tools and preparing cost vs. benefits/Usage comparison – Nitin
 Implementing the selected tool to scan code repositories and generate vulnerability
reports – Nitin and Mentors
 Fixing the reported vulnerabilities in order of priority (Critical, High, Medium and
Low) by product team members – Mentors.
 Code reviews are started proactively for all code changes and every review should
include at least 3 members (including one from different product team). - Mentors.
Timelines: 6 - 12 Months. Fixing of Critical and High vulnerabilities should be completed before
PCI audit.
Key Points to Note: Timelines are dependent on the POCs and approvals for purchasing the
chosen tool. Some part of teams’ bandwidth will be utilized in fixing Critical and High
 vulnerabilities on priority which could impact the delivery date of few deliverables.

2. Spend time on Design workshops to create right and clean product design with long term vision
to avoid rewriting product code again. Focus should be on designing right the first time. Standard
file naming conventions should be adopted.
Priority: Medium
Actions and Owners:
 Work with Mentors, Nitin and Chirag to set up the process and expectations – Neeraj
 Driving and tracking weekly progress till the time process is matured - Neeraj
 Ensure that design reviews are happening for new changes post discussions with
Business stakeholder team and any changes or suggestions are communicated back
and aligned. – Mentors
 Ensure that team is following standard file naming conventions as per standards –
Mentors
Timelines: 6 Months.
Key Points to Note: Any new changes will not be immediately started. It will be analyzed and
reviewed post which estimations will be done and sprint planning will happen.

3. GIT branching strategies should be used properly and timely code merges should be done to keep
Development, UAT and Production codebase in sync. This should happen across all products.
Release versions should be baseline and maintained.
Priority: Medium
Actions and Owners:
 Work with Mentors, Nitin and Chirag to set up the right GIT repository branching
strategy – Neeraj
 Driving and tracking weekly progress till the time the agreed and aligned changes are
complete - Neeraj
 Ensure that new changes are communicated to the team and are being followed –
Mentors
 Proper code merges are happening at the right time and release baseline is maintained
with proper tagging - Mentors
 Product code which is still using SVN should get migrated to AWS Code Commit. –
Mentors
Timelines: 6 - 9 Months.
Key Points to Note: This is a little tricky task and may face few challenges. There could be some
impact to deliverables whenever the team undertakes this migration and repository refinement
task as it needs carefully planning and complete focus.

QA Practice

QA is an important part of development life cycle. Quality assurance is a quality management process
that consists of establishing standards, guidelines and procedures to prevent quality issues and maintain
the integrity of the product or service throughout its development.
Tech Team- Mentor: Milin. Members: Jai, Riya, Nidhi, Omkar, Ambika and Neerav

Strengths
1. Good knowledge of all the Products is available in the team.

Weaknesses
1. Automated Testing is not present.
2. QA team strength is not adequate.
3. Testing team is engaged too late in the development process. QA team is engaged only when
changes are ready and pushed to UAT. QA team has no idea on what the change is, when it was
started, what’s the plan and which systems it’s impacting. There is no documentation
(BRD/FRS/SRS).
4. Testing narrations are given to QA team by developer rather than Business team/Product
Manager.
5. Around 50% of the APIs are not tested.
6. Testing effort is not estimated in delivery plan so nothing gets tested completely with full
confidence.
7. Developers are not doing Unit testing. Many of them are not aware of Unit test concept.
8. Defect logging tool is not there hence defect fixes does not follow any life cycle and cannot be
tracked properly. Developers only fix bugs which ever they feel are important.
9. No support for multilingual site testing and regression testing. Cascading effect of any change are
not analyzed and tested properly.

Opportunities
1. Testing has scope for lot of opportunities to create right kind of testing practice in the
organization.
2. Testing team could evolve to adapt more matured QA processes.
3. Yearly Roadmap (or at least for next 6 months) should be shared with the QA team in order to
bring visibility to the upcoming changes which will help to plan the work and team strength
better.

Threats
1. Absence of Automation, security and regression tests could result in rendering the product
completely useless over time.

Recommendations
1. Testing team strength should be at least 30% of Development team’s strength. QA team needs to
be built with this goal in mind for near future.
2. Automation Engineers should be hired who could create automation test suite for Backend
functionalities and frontend UI features.
3. Security testing should be enhanced to avoid outside attacks and threats.
4. Cross browser testing, Performance and load test should be introduced as part of product releases.
Performance test engineers should be hired as well.
5. QA team should be engaged from beginning when the requirements are finalized and dev team is
 ready to start work on it. QA team should have the responsibility of understanding the BRD
(Business Requirement Document) and creating independent test cases/scripts, getting them
reviewed and approved by Product Manager/Business team and use that for extensive testing.
Product manager should engage the QA and development team at the same time.
6. Proper test estimations should be created and included as part of the final delivery plan.
7. Developers should perform unit test on their code before pushing it to QA environment for QA
team to test. They should also write JUNIT or other test scripts to facilitate Back End automated
testing.
8. Defect logging tool should be used to log, track and manage defect life cycle. Product managers
should be involved for prioritization of defects. Recommended Tool: JIRA
9. Since MyBookingSite is going to have multilingual support, one person should be trained or hired
to support multilingual testing. Cascading effect of any change needs to be analyzed and tested
properly.
10. Any ticket should first go to QA team to reproduce the issue and then developer should be
engaged to fix. Mostly tickets are going to developers directly for fixing without engaging QA
team. QA team is engaged at will if developers/mentors feel it’s important to test.
11. Core Products like SU and MAX should have a dedicated testing team of at least 4 people each.
SU an Max needs to be tested carefully involving automated regression tests before every release.

Recommendations Execution Plan

1. Testing team strength should be at least 30% of Development team’s strength. QA team needs to
be built with this goal in mind for near future. Automation Engineers should be hired who could
create automation test suite for Backend functionalities and frontend UI features.
Priority: High
Actions and Owners:
 Work with Milin, Nitin and Chirag to analyze QA team expansion needs for
Automation, Load/Performance tests and functional tests. – Neeraj
 Work with Milin, Nitin and Chirag to identify additional software / Tools needs for
Automation and load test scripts creation - Neeraj
 Create a plan, get approvals from Board and drive the approved plan - Neeraj
 New Team build UI and Backend automation scripts and load test scripts for
approved products - Milin
 Load tests (for Key Products) and Automation tests are run prior to every release and
test cases are being updated with new changes post release – Milin
 Unit tests are built and executed by developers before passing the sprint story to QA
team for testing - Mentors.
Timelines: 12 Months.
Key Points to Note: Timelines are dependent on hiring the right people and how soon they
become productive. Some part of development teams’ bandwidth will be utilized in building unit
tests for existing functionalities which could impact the delivery date of few deliverables.

2. QA team should be engaged from beginning when the requirements are finalized and dev team is
ready to start work on it. QA team should have the responsibility of understanding the BRD
(Business Requirement Document) and creating independent test cases/scripts, getting them
 reviewed and approved by Product Manager/Business team and use that for extensive testing.
Product manager should engage the QA and development team at the same time.
Priority: High
Actions and Owners:
 Work with Milin, Nitin, Chirag and Business team to discuss and create a process
where Mentor, Product Manager and a QA team representative is included in
requirement discussions – Neeraj
 Ensure that QA team members are included in requirements discussion and a proper
BRD is created by Product Manager/Business team. Any changes to requirements
should also be communicated to QA team. – Product Manager
 QA team creates the test scripts for the new requirements and get them reviewed and
approved by product manager/Business team - Milin
 Ensure QA team uses the new scripts for new feature testing effectively - Milin
Timelines: 6 Months.
Key Points to Note: A new Product Manager should be hired to document the requirements into
BRD, get it reviewed and approved, transform the requirements into user stories and works with
development team and Business stakeholders for clarifying the requirements as needed and drive
the development sprints.

3. Defect logging tool should be used to log, track and manage defect life cycle. Product managers
should be involved for prioritization of defects. Build dedicated teams for SU and MAX
Priority: Medium
Actions and Owners:
 Evaluate with Milin and Nitin if Zoho Tickets could be used for logging internal
defects. As per team, Zoho ticketing works well for customer issues but not for
internal incidents and defects (Security team is thinking about using JIRA system for
incident management due to above reason) – Neeraj
 Drive and track the progress on a weekly basis till the time process is mature enough
- Neeraj
 Ensure every defect is logged into the system and it follows the complete defect
lifecycle with proper closure (including logging, prioritizing, fixing,
reviewing/testing, closing) – Milin
 Ensure SU and MAX has a small dedicated team for testing exclusively as these are
Staah’s core products - Milin
Timelines: 6 Months.
Key Points to Note: Additional time commitments from business stakeholder team will be needed
to review and prioritize the defects.

Team

People are the biggest resource for a company and can affect public perception of our brand. The
employees are the true assets of an organization. They are the ones who contribute effectively towards the
successful functioning of an organization. Employees are our brand ambassadors — the face of the
company. If employee retention is low and tenure is short, new client acquisition may prove to be more
difficult.

Strengths
1. Good average tenure of employees in the company.
2. Employee turnover ratio is quite low.
3. Employees feels their work and contribution is valued by the company

Weaknesses
1. Many of the employees were hired as fresher so cross company experience is less.
2. Fresher and interns are considered as part of productive team with code delivery expectations.
3. Proper employee mix of experienced, cross company experienced and fresher is missing in the
product teams.

Opportunities
1. Communication skills of individual team members need improvement.
2. New Architect is not getting enough bandwidth to gather in-depth architecture and component
understanding of all products. He is being too involved into MAX system. There is opportunity
for him to understand Staah Technical products Architecture and landscape.
3. Learning opportunities - senior team members can organize 1 or 2 day training sessions for junior
members to attend and learn new things which could be technology related sessions or new
features added to the product. These sessions should not be at product level but at organization
level. Few learning opportunities could be:
a) Weekly Knowledge sharing sessions
b) Monthly mentors meeting (mentors can decide the agenda)
c) 1 - 2 day training sessions by mentors or external trainers.

Threats
1. High dependency on Mentors for every product.

Recommendations
1. Fresher and interns should not be loaded with delivery expectations for first 3 months and not
more than 50% for next 3 months which should be considered as training and learning period for
them. Focus should be more on building tech capabilities as well as product knowledge.
2. Chirag should be groomed more as an overall Architect to focus more on the products
Architectural landscape and improvements.
3. Proper Mentor backups should be created to avoid any threats to the product in case few mentors
decide to leave abruptly.
4. Some communication skill trainings should be arranged in batches to improve communication
skills across the organization.
5. For future employee requirements, consider hiring more percentage of people from other
organizations as that will bring in external perspective and experience and will help in improving
best practices and product code and design further. If local resources in Surat are not available
 then consider hiring few resources working remote (Not more than 20% per product).
6. Induction program should be introduced for new team members which should include few
mandatory trainings like Secure Coding practices, Workplace ethics, IT Security (Malware, email
phishing, ransom ware etc.) etc.
7. Alternate Saturday working is not preferred by the team. Would recommend making all
Saturdays off and adapting to 5 day working culture. This might have contributed to losing few
good experienced recruits from outside who prefer working in 5 day week organizations.
8. Experienced team members should be identified and motivated for AWS certification. This will
help in building teams capability as well as provide more strength to Staah's brand value.
9. People should be motivated and encouraged to learn new skills and technology.

Recommendations Execution Plan

1. Mentor backups should be created to avoid any threats to the product in case few mentors decide
to leave abruptly.
Priority: Low
Actions and Owners:
 Work with Mentors to analyze the backup readiness and gaps and create a plan to
bridge the gap. – Neeraj
 Drive the plan and track weekly progress - Neeraj
 Create effective backups for their products - Mentors
Timelines: 6 Months.
Key Points to Note: Work priorities and unavailability of suitable resources could impact few
product backups.

2. Communication skill trainings should be arranged in batches to improve communication skills

across the organization. Induction program should be introduced for new team members which
should include few mandatory trainings like Secure Coding practices, Workplace ethics, IT
Security (Malware, email phishing, ransom ware etc.) etc. AWS certification should be
encouraged.
Priority: Medium
Actions and Owners:
 Work with Nitin, Chirag and Mentors to identify teams training needs. – Neeraj
 Work with HR, Nitin and Chirag to figure out what trainings could be provided
internally and what will be needed as classroom training (online/offline mode) –
Neeraj
 Work with HR to create an Induction program for new joiners and identify which
trainings could be included as part of Induction program – Neeraj
 Identify and nominate people for AWS certification – Chirag, Nitin and Mentors
 get leadership approvals for AWS certification costs and other training costs = Neeraj
 Work with HR and Mentors to create the yearly training programs which teams could
plan and attend – Neeraj
 Track the progress of the training and Induction program till the time it becomes
BAU (Business as Usual) - Neeraj
Timelines: 1 Year.
Key Points to Note: There could be costs involved with some of the trainings and AWS
 certification.

Downtime SLAs and Disaster Recovery

Disaster recovery is a method of regaining access and functionality of its IT infrastructure and systems
after events like a natural disaster, cyber attack, Data centre outage or complete cloud region downtime.
These disasters disrupt business operations, creates customer service problems, and result in revenue loss.
A disaster recovery plan helps organizations respond promptly to disruptive events and provides key
benefits. A variety of disaster recovery (DR) methods can be part of a disaster recovery plan. Some of the
key benefits are:
 Ensures Business continuity
 Enhances System Security
 Improves customer retention and builds customer confidence in organizations system stability
and reliability.
 Reduces recovery cost

Strengths
1. One EC2 backup is taken monthly by Nitin. This is a manual process.
2. Some mentors (for example 'My Booking Site' AKA MPS New Booking Engine Mentor) are
thinking of setting up multi region support for Disaster Recovery

Weaknesses
1. No Disaster Recovery setup in place currently.
2. RTO/RPO is not defined.
3. Downtimes are responded in reactive mode.

Opportunities
1. Proper Support and downtime SLA model does not exist currently. There is an opportunity to
create a proper downtime support model with standard SLAs (Service Level Agreements).

Threats
1. In the absence of DR setup, any disaster could lead to an indefinite downtime causing loss of
revenue and clients confidence.

Recommendations
1. Active - Passive or Active - Active cross region Disaster Recovery setup is needed. Time and
resources should be utilized to actively work on a DR setup strategy.
2. RPO (Real Point Objective) and RTO (Real time Objective) should be defined for critical
products and strategies should be devised to achieve these defined targets.
3. Standardize backup strategy for Live RDS DB. A proper strategy should be formulated and entire
process should be automated.
4. Product deployment strategy should be planned and created in a way which should make them
cloud independent. Team should be able to deploy products in cross cloud platforms with ease
 and without much rework in case a need arises.

Recommendations Execution Plan

1. Active cross region Disaster Recovery setup is needed.
Priority: Medium
Actions and Owners:
 Work with the team on preparing a strategy and plan for cross region Disaster
Recovery setup. – Neeraj
 Create a proposal including resource and cost estimations for this setup and present to
board for approvals - Neeraj
 Drive the plan once approved and track weekly progress - Neeraj
 Create Disaster Recovery setup – Nitin, Chirag (AWS support team)
Timelines: 12 Months.
Key Points to Note: Start of this initiative (and few others) might start late if other priority
initiatives are running in parallel. Need to decide if we need Active – Active replication or Active
– Passive replication.

2. Standardize backup strategy for Live RDS DB. A proper strategy should be formulated and entire
process should be automated.
Priority: Medium
Actions and Owners:
 Work with Nitin on preparing a strategy and plan for RDS DB backup. – Neeraj
 Work on cost estimations and approvals from board (as needed) - Neeraj
 Drive the plan once approved and track weekly progress till the time process is setup
and is running smoothly - Neeraj
 Execute the approved plan – Nitin
Timelines: 6 Months.
Key Points to Note: Start of this initiative might start late if other priority initiatives are running in
parallel.

Partner Support and Business Team

Partner support is important in resolving customer grievances and has to work efficiently with both the
customers as well as the IT tech support teams. Similarly, Business team should also work efficiently
with IT tech team to ensure that product roadmap, change requests and deliverables are managed
efficiently. Proper communication channel and a strong/stable and efficient process setup are very
important in achieving the above goals.

Strengths
1. Business team (Gavin, Angie and all) are very approachable and appreciates the team for their
efforts.
2. Any developer can approach Gavin directly for any clarifications. This motivates the team a lot.
3. Business team with key people like Gavin, Angie, Cheyenne etc. is quite strong and had
 considerable past experience.

Weaknesses
1. Business Team goes directly to developers at times for new development changes or existing bug
fixes. At times even mentors are not aware and are not in loop.
2. There is no controlling authority on the IT leadership side to steer the team in right direction, act
as a link between the team and Product stakeholders and implement appropriate checks and
controls.
3. There is a rush to deliver new features most of the times which impacts quality. KPIs linked to
faster deliveries are also contributing to it.
4. In the absence of standard processes, Business team does not get regular timely visibility into
 What task/stories team is working on
 Why the deliveries are taking long and getting delayed
 Regular updates
 Test cycles and bug tracking reports
 Why release of one feature breaks another feature (primarily due to missing regression tests)
5. There is no documentation available for products.

Opportunities
1. Identify ways to resolve funding concerns for quality services and software to make product
landscape more robust and reliable.
2. For any new products or features, Demo should be arranged for all the mentors and Team
members who are interested in learning about it. This demo could be around business
functionality and technical architecture.

Threats
1. Missing IT leadership is a risk to the overall well being of the team. It could render the team
directionless with no sense of future vision and company strategy.

Recommendations
1. Business team should have a single point of contact for each product that they should coordinate
with for any new or existing piece of development. This person could be the product mentor or a
designated Product Manager associated with the product.
2. Create an IT leadership team to steer the team in right direction, oversee important IT practices
being followed, processes being implemented and works as a link between the team and the
Business team.
3. Critical and complex products like SU and Max should have a dedicated product manager. Some
senior folks should be hired from outside to fill this position.
4. Balance between quality and speed needs to be created. Time to market is critical but a realistic
time frame should be allowed for any new feature to ensure quality is not compromised.
5. Create architecture, security, functional, design and SLA (Service level Agreement) documents
for every product.

Recommendations Execution Plan

1. Create IT leadership and establish process for business requirement communications. Product
managers should be hired.
 Priority: High
Actions and Owners:
 Work with the Leadership team on hiring IT leader separate from Gavin’s role. Gavin
role should primarily focus on driving the business requirements and new ideas. (This
is the position for which Neeraj was interviewed and engaged) – Recruitment team
 Work with Business team and Mentors on setting up business requirement
communication process. Identify SPOCs for each team (preferably Mentors) who
should be contacted to initiate discussions around new features. Mentors should
engage QA team members as well in these discussions. - Neeraj
 Work with leadership team on hiring separate product managers for SU and MAX -
Recruitment team
Timelines: 6 Months.
Key Points to Note: There may be quality resource issues if we only look for local candidates.
Some part of hybrid working should be considered to hire quality resources for these positions.

2. Balance between quality and speed needs to be created. Time to market is critical but a realistic
time frame should be allowed for any new feature to ensure quality is not compromised.
Create architecture, security, functional, design and SLA (Service level Agreement) documents
for every product
Priority: Medium
Actions and Owners:
 Work with the Leadership team on setting right expectations with the business team
on the quality related changes proposed and agreed for execution – Neeraj
 Work with mentors and identify which document exists and which needs to be
created for their respective products. - Neeraj
 Update existing documents and create missing product documents. - Mentors
Timelines: 6 - 12 Months.
Key Points to Note: There could be delay in completing the documentation in case other priority
tasks are running in parallel.

Infrastructure, Security, Monitoring and Logging

Information technology infrastructure consist of components required to operate and manage enterprise
IT environments. Staah IT infrastructure is within AWS cloud computing system. These components
include hardware, software, networking components, an operating system (OS), and data storage, all of
which are used to deliver IT services and solutions. All these components should be reliable and should
have the capacity to handle the peak load system needs.
IT security is the protection of information and especially the processing of information. IT security is
intended to prevent the manipulation of data and systems by unauthorized third parties.
Monitoring is used to collect health and performance data from servers, virtual machines, containers,
databases, and other backend components in a tech stack. Engineers can use an infrastructure monitoring
tool to visualize, analyze, and create alert on metrics and understand whether a backend issue is impacting
users
Every component in a network generates a different type of data and each component collects that data in
its own log. Proper logging and storage strategies should be created to ensure smooth running of the
system.
Tech Team - Mentor: Nitin. Members: Aakash, Shrey, Rini, Anagha, Yesha

Strengths
1. Cloud watch tool is being used for monitoring in few products.
2. One QA person is learning Zap security tool for threats like (Man in the middle attack, Fuzzing
attacks, Brute Force attacks etc.) using Zap tool. PEN test is also being conducted in some
capacity.
3. Few Security tools like AWS Inspector, Antivirus Crowd strike is being used in Production
environment.
4. Wazhu tool is getting used for PCI compliance. It covers most of security aspects. Apptrana is
being used for WAF.
5. Team has few strong members like Nitin and Aakash.

Weaknesses
1. Server load is checked manually by mentors at irregular intervals. Proper monitoring setup and
alerts are missing.
2. There is not a proper separate team to focus on Security. Nitin and Aakash are trying to build it in
some capacity.
3. Client data is vulnerable. Team members have access to client Personal Information (PI).
4. System Monitoring and alerting Process needs a lot of improvement. Absence of monitoring and
alerting system could result in issues and threats not getting caught at the earliest causing system
and revenue impacts.
5. Wazhu is a good security tool but is open source and does not have good log mgmt. It does not
have any support. For big systems with heavy logs, it’s not usable as it crashes.
6. Logging strategy is error prone and is causing issues in few products. Logs backup scripts exist in
multiple languages (PHP, Pearl, Python etc.).
7. There is no backup for Nitin and Aakash.
8. Documentation is kept in emails.
9. Security team has no way to check if Code or SQL queries are secure.

Opportunities
1. Extend antivirus (Crowd strike) to development and QA environment.
2. Explore AWS security framework features for end to end security, logging and monitoring.
3. Non PCI cron servers could also be brought under PEN scans.
4. Security framework which is being planned for production could be extended to Dev and QA
environments as well.
5. Adopt proactive approach rather than reactive where security is involved.
6. Formulate Security policies, review them, standardize them and publish them. Security policies
need to be practiced seriously across the company.

Threats
1. Old Payment gateway should be retired ASAP as it’s an old one and could be an issue for PCI
compliance.
2. Cron servers are not protected adequately. There is risk that these servers could be compromised.
 3. Code is never reviewed from Security vulnerability aspects nor there are any standard code
review tool integrated in the development process. This could result in outside attacks
compromising the product.
4. There is no backup for Nitin and Aakash.

Recommendations
1. Proper load and performance monitoring tools should be integrated and alerts should be created
using tools like Splunk.
2. Create a separate Security Team (could start with 3 people) to address security testing like PEN
test and other threats and no Production release should happen without a signoff from Security
team.
3. Client data should be protected and segregated. Only authorized personnel should get access to
client data. A good video providing clear concepts on data privacy could be found here:
https://www.youtube.com/watch?v=3Ex0GXyo79g
4. Proper Monitoring and alerting system should be setup along with 24/7 support to alert and act on
any threats or system issues.
5. Image upload strategy should be created. Clients should not be allowed to upload images beyond
a certain size as it could choke up network bandwidth resulting in performance issues.
6. Add additional server under load balancer for applications like PMS, Deamon etc. which has
single servers. This will serve as a backup and will avoid downtime during critical patches.
Currently critical patches are delayed on these servers to avoid downtimes.
7. Replace Wazhu with good alternatives like Qualys VMDR, Sumologic, DataDog, Ubuntu Pro etc
(This is Work In Progress).
8. Integrate code review tools such as Checkmarx, Checkpoint or Snyk to address security
vulnerabilities in code.
9. Adhoc logging solution across products should be reviewed and move to standard logging
strategies where logs could be used in a more meaningful way. It should be created as a micro
service so all products could use the same standard service.
10. Move organization email to Microsoft office 365 with Teams as internal communication tool.
Product alerts should go from product domain.com or staah.com and not gmail.com.
11. Interview and meetings happening sometimes over Skype and sometimes over Google Meet. One
standard tool (like MS Teams) should be set as a preferred internal communication tool with
proper meeting invites with single URL for all to join.
12. Create backups for Nitin and Aakash. This will also help in support rotation over weekends.
13. Important communications should remain documented in email. They should be documented
properly using some tools like JIRA or ServiceNow. Zoho is not working out for security team
documentations.
14. Add a Database specialist to the team to review SQL queries and ensure it has no security
vulnerabilities.

Recommendations Execution Plan

1. Create a separate Security Team (could start with 3 people) to address security testing like PEN
test and other threats and no Production release should happen without a signoff from Security
team. Proper load and performance monitoring tools should be integrated and alerts should be
created using tools like Splunk, Data dog, Sumologic etc. (In Progress). Support team should be
built to monitor the alerts.
Priority: High
Actions and Owners:
 Work with the Leadership team on budget and approval for right size security team
and tools to enhance security and monitoring aspects of Staah – Neeraj
  Work on POCs to select the right tools and hire the right team – Nitin and Neeraj
 Install the security and monitoring tools and train the new team. Setup 24/7 support
team to monitor alerts proactively - Nitin
 Review the tools and traffic periodically to optimize related costs – Nitin and Neeraj
Timelines: 6 – 12 Months.
Key Points to Note: Few aspects might get delayed due to other priorities.

2. Client data should be protected and segregated. Image upload strategy should be created. Clients
should not be allowed to upload images beyond a certain size as it could choke up network
bandwidth resulting in performance issues. Add additional server under load balancer for
applications like PMS, Deamon etc. which has single servers. Integrate code review tools such as
Checkmarx, Checkpoint or Snyk to address security vulnerabilities in code. Adhoc logging
solution across products should be reviewed and move to standard logging strategies.
Priority: Medium
Actions and Owners:
 Develop a strategy and create a solution to protect and segregate client PI data and
get it implemented for all products. – Chirag, Nitin and Neeraj
 Review image upload workflows and create necessary restrictions around size and
secure uploads – Nitin and Chirag
 Work with stakeholders and plan to bring applications like PMS and Deamon under
load balancer. Secure approvals from board for any additional cost – Nitin and Neeraj
 Secure approvals for code review tools and ensure its installed and utilized in an
optimized way – Nitin and Neeraj
 Review the logging strategy and work towards creating a uniform strategy which is
both optimized and resilient and does serve the logging goals. – Neeraj, Nitin and
Chirag.
Timelines: 12 - 24 Months.
Key Points to Note: Few aspects might get delayed due to other priorities.

3. Move organization email to Microsoft office 365 with Teams as internal communication tool.
Create backups for Nitin and Aakash. Important communications should remain documented in
email. Add a Database specialist to the team to review SQL queries and ensure it has no security
vulnerabilities.
Priority: Medium
Actions and Owners:
 Align with leadership and Adapt to Microsoft office 365 email solution for
organization emails and Teams as internal communications and meetings tool –
Neeraj and Nitin
 Work with leadership on a strategy to create backup for Nitin and Aakash (Mainly
Nitin) – Neeraj
 Document all key events and incidents using a suitable tool (ZOHO or JIRA) -
Aakash
 Review the DB specialist need with Nitin, Chirag and leadership and hire a specialist
DB developer. – Neeraj
Timelines: 6 – 12 Months.
 Key Points to Note: This will need alignment and approvals and delays might happen in the
absence of skilled resources in Surat.

Products

1. Voucher System
Tech Team - Mentor: Rony. Members: Vrushika

Observations
1. Team is fine and has a good balance of skills. Its size is optimum with respect to current
workload
2. Extranet and booking engine are used for voucher creations. These systems are using 2
different UIs.
3. Voucher creation happens in Voucher system directly as well as in sales force system via
sales team.
4. Code was never reviewed. It could have substantial technical debt.

Recommendations
1. Development of new UI is in progress. JQuery version 1.9.1 could be migrated to 3.4.1 in
the interim.
2. From experience and product knowledge perspective there is scope to add one mid level
experience (4-5 Years) person with 50% allocation who could also work as a backup for
Ronnie. Rushika has 50% product knowledge but is too junior to handle the entire
product by herself in case Ronnie decides to leave.
3. Front end is developed using HTML/JQuery. Team should consider migrating it to React
framework.
4. Max eco system is in react framework which will host new Voucher UI. Efforts should be
made to prioritize and release new Max Echo system faster as it will take care of many
shortcomings of Voucher system.
5. Create Voucher system as a service (micro-service) which could be used anywhere using
plug and play framework.
6. Explore possibilities to create a cron job to sync vouchers data regularly between
Voucher and Sales force systems during off peak hours so data in both the systems are in
real time sync. Frequency could be hourly or daily as per the need. Better explore the
opportunity to see if both the systems could use the same database so there is one source
of data to avoid any need of data sync and replication.

2. Max
Tech Team - Mentor: Mayur/Sagar. Architect: Chirag. Members: Prajay, Krushita, Shivani,
Manali, Ankit, Nitesh, Vishal, Kishan and Ekta

Observations
1. Rate calculation in Max is little complex which is a deterrent for customers to migrate
 from Instant to Max
2. Max system is using Instant system IDs so there is database dependency. Instant DB
cannot be removed completely even once all properties are migrated to MAX because of
this dependency.
3. There is good mix of experienced people and fresh graduates in the team though
product/domain knowledge is missing in experienced resources (reason being they are
recently hired and inducted into the team).
4. Technical debt (old code) is there in Max.
5. Higher number of fresher (as compared to recommended ratio) and unorganized interim
support requests affects the productivity and delivery capabilities of the team.
6. Max team is getting thin. Few team Changes are as below:
 Mayur Bhagat - Left STAAH on 28th April 2023
 Prajay Patel - Will be moved to SU
 Krushita Patel - Will be moved to Review Minder
 Ekta Modi - Will be moved to instant websites

Recommendations
1. Simplify design and interface for Max system so migration (from Instant to Max) could
be faster.
2. Explore ways to resolve Database dependency between Instant and Max systems.
3. Hire a dedicated product manager for Max product (In Progress).
4. Build a strong technical team for Max product as its one of the most complex and core
product. Team should have more experienced people and few fresher. 80-20 ratio mix
will be good. 2 more experience persons could be added to the team.
5. Plan to reduce technical debt from MAX.

3. Rate Stalk
Tech Team - Mentor: Rony

Observations
1. Technology used is ASP at Backend, Angular1 and Node Js at frontend and PHP scripts
for scrapping.

Recommendations
1. Explore opportunities to migrate to React framework at Frontend with Python or Node JS
at backend. No issues with ASP at backend but it will be wise to keep similar tech stack
across products to avoid specific dependencies.

4. My Booking Site and APIs

Tech Team - Mentor: Jigar. Members: Darshita. Harsh

Observations
1. Its Server-less Booking Engine deployed on S3
2. Booking engine Front-end is using CI/CD (AWS Code deploy and AWS code pipeline).
3. New Booking engine is using AWS Lambda (serverless) Python APIs. Its look and feel
 and functionality is based on Instant model and is simple and understandable. Frontend is
in react. It’s quite liked by clients.
4. Harsh is backup of Jigar but being an intern is not completely ready.
5. Around 20% technical debt is still present (old lambda code).
6. UI code is new but never reviewed

Recommendations
1. CI/CD pipeline should be created for backend as well.
2. Team should keep trying to reduce the technical debt and optimize the code during
enhancements.
3. Get the code review done by people from other products.

5. SU
Tech Team - Mentor: Trushant. Members: Karan, Riya, Sahdev, Vishal, Hiren

Observations
1. RDS mapping to number of PMS DBs is done after careful analysis. Less than 50% CPU
utilization is there on each RDS during normal load.
2. Migrated SQL to latest version and plan to migrate PHP to version 8.1 soon. This will be
needed for PCI compliance.
3. Riya is the backup for Trushant and is 70% ready.
4. SU design is modular. Receiving, Processing and Posting are designed as separate
components.
5. Prajay will be moving to SU team.

Recommendations
1. Re-evaluate future load requirements for each RDS, create a comparison report showing
current and future load needs and carry out proactive changes as needed
2. Long term Vision should be to move all PMS to SU integration and Hoteliers on Max.
3. Hire a dedicated product manager for SU product.

6. Review Minder
Tech Team - Mentor: Riya

Observations
1. Manual configurations exist in Review Minder to configure the OTAs from which
property seeks the reviews.
2. In case of Properties configured with Max, there is a dependency on Instant system for
review minder configurations. This process is manual.
3. Code is written in Ionic.

Recommendations
1. Explore the opportunity to figure out if manual configuration in review minder could be
automated via API call.
2. For Property configured with MAX, check if dependency on INSTANT could be
removed and if manual process could be automated. Integration with SU should also be
 considered at a later stage.
3. Code should be migrated to latest tech stack as per Org standard.
4. There is no backup person for Review Minder. Ronnie will work on it going forward.

7. PG HUB
Tech Team - Mentor: Ayaz. Members: Pooja, Dhvanika

Observations
1. PG Hub is developed as a separate component to support micro services architecture and
is a central system used across products
2. Piyush is kind of backup person for Ayaz but no one from Ayaz's team is ready as a
backup.
3. Code is following MVC design pattern and has minimal technical debt.

Recommendations
1. Old Payment gateway should be retired ASAP as it’s an old one and could be an issue for
PCI compliance. It could also pose serious threat to the organization in case any security
vulnerability present in it is exploited by attackers.

8. OTA Channels
Tech Team - Mentor: Mukesh. Members: Raunak, Rutwik, Mohit, Harsh, Nitesh, Kunal, Jignesh,
Uday,

Observations
1. Record from the queue is processed in single transaction.
2. Uday is the backup person for Mukesh. He is 100% ready as backup.
3. Deamon code is old. Lot of old spaghetti code is converted to new optimized code.
Around 30% technical debt is still present.

Recommendations
1. Explore if multiple records say 10 (instead of 1) at a time could be processed in a single
transaction from the queue to improve performance.
2. Food for Thought: This could save cloud network usage as well and might bring in
additional cost savings.
3. Re-evaluate the work and required team size. If most of the work is support and minor
enhancements then team should focus on what could be automated or migrated to
efficient designs to reduce manual interventions and efforts and bring the team to an
optimal size.
4. Rewrite OTA integrations code using Python scripts (decommissioning Pearl scripts).

9. PMS Integration
Tech Team - Mentor: Gaurav/Siddhi. Members: Vinay, Riya, Samia

Observations
 1. It mostly consists of backend APIs. 1 Property is connected to 1 Channel Manager only,
either directly or via PMS.
2. Gaurav is moving to other project (Central API system). Siddhi is new mentor.
3. PMS Hub was also planned earlier but was de-prioritized after SU was started.
4. Siddhi is new mentor as Gaurav is moving to Common source centralized APIs and is
100% ready. Vinay is backup of Siddhi and is around 40% ready.
5. 40% code is still in old flow (in Pearl) and not migrated to new PMS flow (in PHP) as
code is sensitive and partners are not quite comfortable with the migration.

Recommendations
1. Explore if PMS Hub is still relevant in some scenarios and could be restarted.
2. Explore opportunities for migration of the old pearl code to PHP.

10. INSTANT
Tech Team - Mentor: Piyush. Members: Jignesh, Keya

Observations
1. It’s written in Pearl. Its interface is coded using old technologies and is poorly written.
2. HTML, Scripts, backend code, all is written in same files.
3. There are performance issues during page load when lot of data needs rendering on the
page. Pagination is introduced on the site to take care of this page load issue.
4. Instant BE engine is in Pearl. That is written well. It was changed fully and is written
using MVC pattern.
5. Jignesh and Keya are backups for Piyush and are 100% ready.
6. INSTANT is stable and only minor enhancements at times are done to it as it’s planned
for decommissioning.

Recommendations
1. Code should be migrated to new technology frameworks using design patterns like MVC.
It’s not relevant in present scenario as efforts are underway to migrate properties from
INSTANT to MAX and INSTANT will be decommissioned eventually.
2. Efforts should be made to complete properties migration from Instant to Max ASAP.

11. MAX Eco System

Tech Team - Mentor: Riya. Members: Amit, Zeenal, Vishal, Bhakti,

Observations
1. New Max system is PHP and smarty combination. Max Booking Engine is in PHP. Front
End is written in React and Back End APIs are in PHP. Tech stack is good.
2. Front End of all products in Max Eco System is being rewritten in React as most of them
were written using old technologies.
3. Existing APIs are being used at the back-end.
4. It’s being worked upon since last 2 years and is still not live

Recommendations
1. Rewrite the old Back-End APIs using new technologies. This will improve performance
 12. Web Design
Tech Team - Mentor: Hitesh. Members: Ankita, Abul, Neeta, Ekta

Observations
1. Separate Design team is there to create professional website UI design
2. Team works with Gavin and Angie for most of the new requirements.

Recommendations
1. For CMS changes, team does the changes and releases it to production in 7 to 10 days
and asks clients to validate. QA team is not involved for CMS testing. QA team should
get involved for each and every change testing howsoever small.

13. New Initiatives

1. Common Source API - This initiative is to create a centralized API system to connect
Staah different products. We have centralized systems like PGHub and CC Vault and
idea is to launch it for external 3rd parties.
They can store CC in our vault and make payment using any Payment Gateway via our
PGHub. Later more APIs and features could be added to this infrastructure. It’s currently
in design phase
Recommendation: Conduct a design review with other mentors and think around
building these services as separate micro services.

2. Property on-boarding via single click - Once any property wants to join Staah, it goes
thru lot of manual workflows which is tedious and time consuming. Idea is to use
Booking.com APIs to get the relevant data, create required mappings, push the data to the
system and onboard the property on click of a single link. Its currently in design phase

3. Serverless Channel - One person created serverless channel in the past. He did complete
one OTA. It was not released or advanced further because the person left and then there
was lack of resource bandwidth to complete the POC. It has potential of saving money as
there are infra costs involved in maintaining channel servers. Costs are there for PMS and
INSTANT as well which could be saved.
Recommendation: Plan some budget for R&D and POCs which has potential of saving
costs to the company. Restart the above POC to figure out if it’s really beneficial.

Recommendations Execution Plan

1. Align on the recommendations and identify the ones to implement.
Priority: Medium
Actions and Owners:
 Work with Gavin and Mentors on identifying and aligning on the recommendations
that should be implemented – Neeraj
 Create an execution plan with timelines and ownership for all such product
recommendations, drive the plan and send weekly/monthly progress updates –
Mentors
  Regular follow-up with mentors on the execution plan progress - Neeraj
Timelines: 6 – 24 Months.
Key Points to Note: Few aspects might get delayed due to other priorities and few might not get
implemented due to operation challenges.

Organization

This section covers specific feedback around Staah's policies, HR and Management in general.

Working well
1. Working environment is good.
2. People are friendly and approachable. everybody (including mentors) helps around when
someone is in need of help
3. There is minimal office politics.
4. Team is happy. Work is challenging and there are opportunities to learn new things which are
encouraged by leadership team.
5. Work timings are good and have some flexibility.
6. Some team events are being arranged.
7. Team gets lot of support from Gavin and Angie and has learnt a lot from Gavin. Gavin recognizes
and appreciate all the good work and efforts.
8. Salary is credited before end of the month.
9. Flexibility of working on new ideas. If anything is trending or comes as new ideas, Gavin
approves it immediately if he sees a value in it. Work is challenging and exciting.
10. Whats up STAAH is a great monthly news letter which provides insight of Staah events
happening around the globe.

Could be improved
1. Saturdays should be made off. Team can provide on-call support over weekends in rotation.
Other organization people see this as an issue while making a decision regarding joining Staah.
2. HR teams question timings sometimes if someone is 10-15 minutes late even though the person is
making up the time in the evening.
Interns concern: HR was rigid during internship and not allowing the interns 2 hours off during
report submission time to their college. They were later asked to complete the time taken for
submission which was around 2 hours per month.
3. HR should observe the behavior and should intervene only if they see someone is regularly
coming late and is making it a habit. One-off occasional cases should be ignored and it impacts
sincere people morale and motivations.
4. Unplanned emergency leaves are not well received by HR team.
5. Need to create backups for Security and Infra support so team could support in rotation.
6. Some machines are old and hang too often. Team need better laptops (I5 with 12 or 16 GB
RAM).
7. Team events or team lunches are not there in HR policy also HR does not support much in this
regard and are mostly seems concerned about 8 hours of working.
8. Guys plan their own events at times (like Trip to Daman) but there is nothing for girls.
9. Surat office is not highlighted much on social media due to which Staah is not getting good
experienced people. Other companies show their benefits as why people should join them. They
show good places to work, festival celebrations, events etc. Staah needs to start that.
 10. Leave policy should be revisited. Team should be allowed to take sick and annual leaves in
advance. Currently 6 leaves can be carry-forwarded and needs to be used within next 6 months
because of which people are on leave during March and June. Some yearly leave carry forward
and encashment options should be considered.
11. QA team morale is not high. Team is not involved into new features and ideas discussions. There
is a feeling that testing team is kind of punching bag. Testing aspect is highly neglected. Mindset
of doing quality work is missing and needs to be created. Everyone needs to understand that they
all are working towards a common goal and not against each other. HR should focus and interact
with all people and not just few.
12. An Intranet site should be created for employees. It should contain general guidelines, policies
and information for employees like HR Policies, Security Policies, Holiday List, Trainings,
contact details etc.

Establish a sustainable IT Cost and Funding Model

Business stakeholders and organization leaders need maximum value from every dollar which is spent on
IT services.

Recommendations
1. Establish a transparent, trusted, and sustainable funding model that accounts for the total cost to
develop, provide, and maintain IT infrastructure and services.
2. Assess the viability of all sources of revenue. Identify and mitigate risks associated with revenue
sources. Balance should be maintained between revenue and IT spends.
3. Ensure that adequate funding sources are identified to ensure that the capability and reliability of
company IT services meet the needs of the organization.
4. Mentors and senior developers need powerful and reliable IT services to create, manipulate,
share, analyze, and store data. Establish the desired research technology services and the
appropriate funding model for analysis and research of cloud (AWS) based products and services
and other frameworks and tools.

Key benefits to the company

1. Establish a culture of financial transparency and accountability.
2. Establishes confidence and trust in prices charged for services that are provided.
3. Reduces confusion by clearly identifying services that are funded one time vs. ongoing.
4. Provides a foundation upon which the value of IT investments may be evaluated.
5. Identifies funding mechanisms to sustain continuous improvement and ongoing effectiveness of
company's IT department.