I recently spoke with Sal Vilardo, who works as a Business Analyst at EMC2 while earning his M.Div. from Southeastern Baptist Theological Seminary. Sal is passionate about people and data, and believes when those two groups align, innovation is bound to happen. You can connect with Sal on his blog, Your Business Analyst Guide, or find him on twitter @svilardo2. In this brief interview, Vilardo talks about his approach to process improvement, his biggest challenges, how he’s overcome them and more.
Schawbel: How do you approach process improvement within your org?
Vilardo: I like to work from the bottom up. The people who are closest to the process are our greatest asset. Those who work within the process every day are the subject matter experts in that area and typically have amazing ideas for improving processes or know of processes that could use some serious consideration. I recently lead a paper work reduction project after one of the techs brought me a stack of paper he printed in a single day and asked, rather exasperated, if there was anything we could do about this. We have since reduced printing output by almost 30 percent throughout the plant. In doing so, we found that there were certain processes where we had automatic print jobs scheduled for no apparent reason. We were able to get some development work and remove those automatic printing steps from the processes which actually sped up the overall process.
I find it increasingly important to listen to those around me who live their process day in and day out. With each conversation, there are hints dropped and clues given as to what is currently the most frustrating part of their day. All it takes is being willing to ask open ended questions and then close your mouth and listen.
Schawbel: What are the biggest challenges you have from a tools / systems perspective to support process improvement?
Vilardo: Access to data is probably my biggest hurdle. As a business analyst and project manager, I need to be able to gather and analyze data against the projected benefits. If that data is either unavailable or is difficult to tie together though the business, then the task of process improvement becomes exponentially more difficult to categorize and relate back to the business as a KPI.
Schawbel: How do you allocate resources / personnel to support process improvement?
Vilardo: There are two distinct ways I have seen resources and personnel allocated to support process improvement. The first is a direct appointment through executive sponsorship. This is exactly how it sounds – we have the approval for a project and the resource requirements get passed down to the respective management teams and they are tasked with assigning resources to the project. The other way is through a voting system where the list of improvements is put before everyone who is looking for resources. These tasks are voted on and prioritized based on number of votes, difficulty, business impact, and length of resource allocation.
Schawbel: What strategies have you found most valuable to overcome those challenges?
Vilardo: I like to utilize two separate strategies to overcome challenges, which often times brings innovation. The first strategy is to tie tasks together. These tasks can be within the same functionality or just utilize similar thought processes. For instance, if you are working on paper flow within your order processing system, and you know that your shipping area struggles with a similar issue, why not tie those two process improvements together to see if they can utilize the same resolution.
The second strategy is the small, incremental burst method, popularized by the AGILE framework. This argues for process improvements in iterations as opposed to huge shifts at any one given time. The way I do this is to find small improvements that do not require much resource time and are fairly simple to fix. I will gather all the requirements myself and see if it would be possible to quickly make the correction (In doing this, I completely open myself up for the resource to utilize – this means I will gather more data, find testers and just about anything else I can do to help out – after all, I want to make sure this extra work has as little impact on the resource as possible). If so, the issue gets corrected and is ready to implement with the next release cycle. These small changes typically add up to substantial process improvements through the business overall.
