Describe a Process You Created

Approach

Let’s approach this question with the classic STAR framework by describing the situation that required the process, the task at hand, the action taken to implement the process, and explaining the result stemming from the existence of that process.

Example Answer

Recently, I worked with our vendor management team to implement a risk assessment program, which hadn’t existed before. The program allows the vendor management team to consistently and rigorously screen our vendors for any risk before we actually use them. The problem, of course, is that vendor requests originate from various teams across the company and there was no process to ingest these types of requests, screen consistently for a standard set of risks, and rigorously test the vendor request before implementation.

That’s where I came in. I researched existing workflows, tested some experimental methods, created the relevant documentation, involved the relevant stakeholders, and implemented a new process. The result has been a smoothly running risk management program for vendor requests.

Follow the STAR framework as it will provide structure to your answer. It's a good idea to provide a high-level answer but be ready to dive deeper if asked to.

Interviewer: That sounds impressive. Can you give me a bit more detail?

Of course! As I mentioned earlier, I first tried to understand what the vendor management team already did when they received vendor requests from other teams. I learned that they contacted the other teams in an ad hoc manner and used their Incident Response procedure, which detailed certain severity levels and the respective SLAs. Here, I assessed whether it was worth creating a new procedure with different SLAs or if it was better to just use the existing one. After talking to a few stakeholders, I decided it made sense to use the existing one to reduce confusion.

Second, I came up with a rough process by writing out the typical steps (e.g. request is received, vendor management team assesses it, the submitting team would be contacted for additional due diligence, and the vendor request is ultimately implemented) and testing it with a few teams. I got immediate feedback that I incorporated into the process around what sorts of information should be given to each team regarding the request, the formatting of JIRA ticket for the request, and more.

Third, I created documentation about the process so that it was referenceable and repeatable across teams. I socialized the documentation to upper-level management to get feedback and buy-in before communicating the process more widely across the company.

Finally, I let the entire company know of the process through multiple channels including email, Slack, group meetings, and all hands presentations.

Highlight more skills in your answer than just process creation; in this answer, you can see examples of teamwork, stakeholder management, and feedback incorporation.

The result has been a smoothly running risk assessment program with critical risks identified and mitigated early on and quick SLAs for vendor requests across the company. Some additional things I did as an extension of this process were setting up an automated email through a JIRA filter to track open tickets related to the outstanding requests and giving people on the vendor management team who identified critical risks a public shoutout to boost morale and the culture of security.

One additional improvement I’d like to have made is a better way of ingesting the vendor request info from the various teams to our JIRA project. Initially, for the proof of concept, we had set up a simple email list to receive vendor requests but it was not as integrated as we would have liked. As a next step, we could configure the email list or create a form that immediately and automatically creates a JIRA ticket, which would lead to better workflow integration.

Discuss where things could be better or improved to show a lack of complacency.

Overall, I think the biggest contributors to success here were the initial testing with teams, the incorporation of feedback, and getting buy-in from various stakeholders before more widely rolling it out. Teams felt involved in making the process rather than just being handed something to follow.

Reflect on why you think your process had an impact. This will highlight a more advanced understanding of effecting change in an organization.

Interviewer: Great. Thanks for your answer.