Encapsulating 2016

The year of 2016 – Interview Question and encapsulating my Eminence and Excellence award at IBM: “Congratulations! You are being recognized in the Eminence and Excellence Cash Award program for demonstrating the Practice: Dare to create original ideas”

Selected Question:

1) Most decisions are made with analysis, but some are judgment calls not susceptible to analysis due to time or information constraints.  Please write about a judgment call you’ve made recently that couldn’t be analyzed.  It can be a big or small one, but should focus on a business issue.  What was the situation, the alternatives you considered and evaluated, and your decision making process?  Be sure to explain why you chose the alternative you did relative to others considered.

Written Response:

As Staff Application Engineer my role predominantly requires me to be technical. Despite the roles title and need for technical abilities, there are also conditions where I am required to manage projects as well as make critical judgment decisions.

When applying for this role in September of 2013, I chose to elect this position among others as it encapsulates the various skills I would like to exercise in my day to day operation: as someone who values the positive impact of software on customer’s lives. In this role from week one I was challenged to understand critical business process; to resolve several project and support issues with the Call Center Customer Relationship Manager (CRM) application to IBM’s executive staff.

To provide some context, the CRM application integrates with several business technologies including: System of Record, Telephony Systems, Enterprise Resource Planning tools and Corporate Reports. In this role there are several instances where I have made judgment calls during several occasions. These may be situations were I’m faced to answer about Project Timelines, Project Resources, Support or SLA commitments, and Technical Solutions.

There are several occasions where judgment calls are made every day as stated above. In this situation I wish to share a event where a project technical decision call had to be made without the analysis due to time and information constraints: A Call Center project requirement was initially defined by the Contact Strategy business group that utilizes agile methodologies to meet its business process technical needs. This includes defining business requirements through a series of meetings and email thread (no specific Agile tool-set or Business Analyst assigned to the project request). These types of technology projects were defined as End User Computing (EUC):  A technology project process that has been approved by Senior Technology and Business Managers without the involvement of software developers input or assigning a Business Analyst to the project for authoring Functional Design Specifications.

This project involved a major change request for the Call Center CRM application. The development of the software changes were to be implemented by the vendor of the CRM application. Due to the project complexity and unite of work required to meet the project goal a timeline of one year was given by the business owner of the CRM application. My role in this project includes: Project Management (Setting up meetings with stakeholders including the vendor development lead to meet functional goals in a given timeframe); Product Management (Making sure changes to the project including functional are not to impact project budget); Technical Solution Management: (Making sure requirements and product outcome meet architectural and compliance constraints); Release Management: (Making sure the release of the product aligns with Data Center Operation technical requirements as well as the SDLC process set by the technology team).

As you can imagine the technical SDLC process does not align with the Agile process of the Business group. There was also a bit of complexity as the stake holders for financing the project was driven from the Telephony team which required a separate process for procuring the development effort from the vendor. The vendor also required a separate Project Manager from the telephony servicing company to manage this projects effort.

An iterative process was taken to resolve several issues including missed requirements by the vendor. On the last release of the application which was delivered late in the project milestone while running tests, I discovered a critical issue with the back end implementation of the application: As oppose to developing a new database table for managing the new functional process, an existing table (result table) was used. This creates confusion for determining which records are results as oppose to start/initial datasets. At this point a Sales Engineer from the vendor was deployed from Europe strictly for one week to demo the project solution to all stakeholders. On discovery of the implementation error I took the first step to mitigate this issue: setup a meeting between all technical stake holders and the business owner of the project. From the vendor side, the development manager took ownership of not understanding requiems correctly and advised to resolve this issue within a month. The Business Owner (client side) was frustrated. The core issue also involves the Enterprise Data Warehouse (EDW) not being able to differentiate new versus completed datasets. The vendors project manager had no response or input to any of the findings.

The Business owner on the same day followed up with a meeting between me and my Manager to see if we can implement a workaround for the issue in order to keep the commitment to our company’s client. The commitment to the client meant several million dollars at stake per month due to compliance and inefficient business processes. This meant having a technical solution (not a change in the business process) to utilize the new CRM by the vendor and develop an internal solution to resolve the critical issue. This was a question I had to answer during the call due to a meeting that will take place between our company’s president and our client on this projects status.

I had technical knowledge however creating in-house solution may require further integration with EDW technical team.  This also meant additional change may need to be made as it impacts all other integrated applications I have covered on my third paragraph above. The alternative was to push back and re-engage with the CRM vendor. This would be more ideal and in the long term provide better support process with any development issues. Further more, deeper testing of the new CRM would take place to find any functional gaps as well as bugs. I know that was not the answer my client (the business owner) wanted to hear. Relatively it was also not what our company’s president wants to hear. Our client would also consider the risk of not being able to meet our commitments. During the call I asked my manager if he can commit to adding additional development team member (internal and not from the vendor) to which he agreed.  I also asked the CRM Business owner if he can commit to adding a Business Analyst in order to clearly define the functional requirements; to which he also agreed.

At this point, based on my technical experience and working with several different development groups I know a technical solution can always be developed. The only question was if it can be sustainable. The commitment from my manager and business owner will make the new solutions development and support effort manageable. For that reason I made the call to take ownership of implementing an internal solution to the vendors missed requirements. Making the call to take the responsibility was also a calculated to some degree. I considered the timing of Sales Engineers presence to be valuable in providing further details about the new features of the CRM to the Business Analyst.

To execute this call, I leveraged my new development team member to create Software Design Specification based on the current known CRM solution. From there I consulted with the Business Analyst (BA) on how we can define new data points to resolve the core issue. Once the BA has authored the piece of solution for the changes in the Functional Design Specification (FDS), I set up a daily meeting with technical stakeholders only to design the solution in our development environment. After two weeks of effort, the solution in our Development environment was completed. We were able to successfully deploy the new CRM to Production within one month of completing QA efforts the following week.

The outcome of this project integrated with in-house solution was a success despite. The result of having a complete design of the CRM solution (which did not exist prior to this project) was invaluable. It become the model for our organizations FDS standards. It was also helpful in resolving some of the Production issues that ware not caught during the tests. Ultimately the CRM new functions has put our company in compliance ahead of our competitors. More importantly it met our clients needs and made there customers delighted.

Kidus Yared