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
