October 20, 2016 Brandon Nalband

Technology & Tools: The Importance of Process

As a technology company, Duo is in the business of providing an application that solves a problem in the security industry - ease of use. At the root of our brand is changing the way businesses and users approach security. We pride ourselves on providing a Trusted Access platform that can be integrated into security processes and is easy to use.

However, our tech doesn’t solve all of the problems that security professionals face within their respective business. For our solution to be effective, admins must use it in conjunction with other existing security practices.

I ran into the issue of trying to use technology solutions to solve the issues our Marketing team was facing here at Duo. I learned a valuable lesson that sometimes looking inward, rather than outward to solve a problem is the best solution. The fundamental principle for achieving desired outcomes and user adoption is the recognition that technology is just one of the pieces to a much larger puzzle that creates efficient and effective processes.

Celebrate Failure to Achieve Success

The Creative team at Duo is part of the Marketing team. We are a group of designers, developers, writers and videographers that strategize and execute projects to further explain and express our brand through different mediums. I joined the creative team a little over a year ago and was responsible for identifying the problems our team faced with managing projects and implementing a solution for them. Some of the problems we faced as a team were around:

• Project organization and communication
• Timelines
• Visibility to those outside our department

I researched and decided to implement a project management tool that improved our project organization and inter-department communication. However, we still faced issues with cross-department communication.

Because the tool was only adopted by our team and wasn’t visible to the rest of the Duo team, we weren’t able to assess current project status or dependencies that were blocking us from moving forward. Most importantly, we didn’t have centralized place for all project participants to reference, which resulted in more communication issues within our internal team.

We moved onto another project management software and again found a similar result. The kanban project management methodology worked for me as a project manager and helped the team move projects along visually, but it still lacked a solution for communication problems that we were facing. Our team never fully adopted it and once again, we faced the same challenges.

So why did we continue to fail in solving for these problems? At this point, it started to become obvious that tools weren't the issue, but rather processes and how we worked as a team. I started to dissect how we worked and found the areas that contributed to failure of implementing technology as a solution:

1. We never had a clear use case for the tool because we never documented how we actually work through a project.
2. Our goals were narrowly focused on our own departmental communication when the majority of our work relies on cross-department communication.
3. There were already a variety of tools being used company-wide that people were familiar with and had already adopted.

When we implemented a new solution, it was just another tool.

As I worked through the issues I identified above, I realized that I had allowed technology to become the focal point for how we worked. Technology however, could only assist us and was not a solution to our problems. We needed to look at our process before implementing tools in order to be successful.

Improving Our Process

Now armed with lessons learned from the failed attempts to improve our project management process, I started breaking down not only how we worked as a team, but how others worked with us at Duo.

As an in-house agency serving every department, there is never a shortage of incoming work. At the core of our communication issues, the Creative team was viewed externally by other teams in the company as the people that merely added bells and whistles to our communications.

We were treated as an entity that operated outside of other departments and were joining projects at the end to make them pretty. We faced issues with prioritizing projects and urgency. This can be detrimental to a creative team who thrives on solving problems and creative thinking. We knew it was something that needed to be improved upon.

I went back to the drawing board, this time, void of any tools, and started asking questions. It only took two questions to start outlining how we worked as a team:

• Why was this happening and how do we get involved at the beginning of a project instead of the end?
• Who needed to be involved and when during a project lifecycle?

To understand why this was happening, I turned inward and surveyed our team. I asked them:

• What was their understanding of their roles?
• What challenges did they face?
• What kind of behaviors did they feel our team exhibited?
• How could we increase visibility to external departments?

In addition, I surveyed our external teams that we worked with and asked them:

• Did they have clarity on roles of our team members?
• What challenges did they face working with our team?
• What kind of behaviors did they feel we exhibited?
• How could we be more visible to external teams?

The responses were incredibly helpful and I outlined activities for a team offsite agenda from them. Using the feedback, we broke off into groups to brainstorm how to improve as a team and individuals, keeping in mind how our working process was perceived by other departments.

What I had learned from this exercise was simple - we needed a framework for setting up a project and that currently did not exist. I came across an interview of Jon Stewart on NPR while working through all of this and he was speaking on how his team put together The Daily Show every day. This excerpt summed up why a framework was important:

You'd be incredibly surprised at how regimented our day is and just how the infrastructure of the show is very much mechanized. People always think, "The Daily Show, you guys probably just sit around and make jokes," and we've instituted — to be able to sort of ween through all of this material and synthesize it and try to come up with things to do — we have a very strict day that we have to adhere to. And by doing that, that allows us to process everything and gives us the freedom to sort of improvise. I'm a real believer in that creativity comes from limits, not freedom. Freedom, I think, you don't know what to do with yourself. But when you have a structure then you can improvise off it and feel confident enough to kind of come back to that. - Jon Stewart

To this point, we lacked structure on how to work with the Creative team. This was the cause of the communication, prioritization and urgency issues we faced when working to complete a project. I outlined a framework that consisted of 5 questions that needed to be answered before our team could start a project:

• What problem are we solving for?
• What does success look like?
• Who do we want to reach with what we are making?
• How does this project connect to our company mission, vision and values?
• Who will need to be involved?

It not only solved the problem of getting involved early, but it opened the door for our team to do what they do best, think creatively with boundaries to achieve a desired result. Our team is now getting involved early in the brainstorming process and seeing a project through from beginning to end instead of being handed something to make it pretty.

Now that we had a framework, I needed to develop a methodology for our workflow to provide visibility into roles and responsibilities for those involved in a project. We implemented the OPERA methodology.

• Owner: The (single) person who "owns" getting the result.
• Participant(s): People who participate in the working group.
• Expert(s): People who are experts, who are consulted as appropriate.
• Reviewer(s): People who don't participate, but review a proposal, whose feedback is incorporated by the Owner/Participant.
• Approver: The (single) person who actually approves the proposal.

By doing this, milestones became clear and how we moved an idea to a deliverable was able to be established. The most important takeaway from working through this was that now each person knows what they are responsible for on any given project and who they effect and need to communicate with if they had to move the timeline.

We have been able to eliminate surprises that often creep up during projects as well as have a plan in place to adjust when the scope may change. Each person understands where they fit into a project and what they have to do for it to be successful. There is visibility into where to go when something is needed at any given stage of a project.

We used this process in our recent Duo in Space promotion and the production plan went without a hitch. From a project management perspective, it was our most successful project to date and identifying these items allowed us to remain incredibly agile because we had clear direction on the purpose of the project.

Introducing Change

Now that we had our process detailed, we were able to look at technology tools in a different light. Suddenly, it all made sense why I had failed before. When I previously implemented tools, I had made technology the focal point of change, failing to gather information from all of the people we collaborate with. Without that information, I had just automated the existing problems, rather than create a solution that was easy to adopt.

In the book Staying Lean - Thriving, Not Just Surviving, the authors stated that research shows that any business process is comprised of 49% to 60% non-value-added activities and 35% to 50% value-enabling activities. Hence, value-added activities only make up 1% to 5% of a process.

I had to take the time to identify value-added vs. non-value added elements in the process that we were changing. Previously, the process led to non-value added activities that continued to exist in the process. This had just led to continued frustration from our team, as well as external departments and we never achieved desired results on projects.

We moved our process into an existing tool, our company wiki, that is visible to everyone here at Duo. Because our new process mostly changed the way our team worked and didn’t involve much change from other departments, they were more willing to adopt use of the tool for communication. We were able to identify the non-value-added elements and eliminate them and provided value to the actions being carried out from those using the tool.

Conclusion

Technology solutions have evolved to support us in almost any activity, professionally and personally. They increase productivity, help us stay organized and can improve communication. They can also be a distraction and create more issues if the reason it is being used is not clearly understood. Using tech to solve for problems that are not clearly defined or within a broken process will only magnify and automate the issues being faced.

As our company and department continue to grow rapidly, we will constantly be refining the way we work. Understanding how we work and why is critical to our success and scalability. It allows us to make the necessary changes quickly and efficiently.