I work for an IT consulting company that has roughly 50 employees. Day to day operations are informal and decisions are typically ad hoc. Since I became manager of our delivery team two years ago as well as joined the leadership team, I tried to find ways to capture data points and use data as evidence for my ideas or reasons for change.
In a startup company of only 5 years, there’s not many data points to drive decisions. Individuals are also resistant to change, fear of changing culture, and have the mindset that the organization isn’t large enough for structured processes. There’s also a sense of paranoia of “big brother” when you ask for more information to be entered on a user interface or rumors spread of reporting on what was people have entered in the past.
From a management and leadership team perspective, decisions were being made through “gut feeling”, opinions of employees, and direction from vendors. There was a sense that the organization kept reinventing the wheel sort of speak instead of improving on key processes and using data to understand weaknesses.
In order to find a starting point, I started asking very specific questions such as: What is our cost for each deliverable of a project?, How much time are being spent in meetings as opposed to working on our deliverables?, or even simpler how do we know who is working from home today?. These questions created a lot of debates but in the end, it created a conversation.
For simple data points like time being spent in meetings and our costs per deliverable, I proposed some changes to our work tracking application. The application has records for information about the project, releases of application development, and time tracking. In order to be very specific on when I would like to capture the data points, I developed a high-level process flow diagram using Visio. It helped me understand when records are created and who is responsible for entering the information. From this view of the process, I was able to better understand the information flow from one activity to another in the process and identify where my data points will be entered.
At the project level, I captured a list of all deliverables for the particular effort. For application releases, I captures all deliverables tied to that release. Releases are then tied to work management and time card records where specific deliverables can be identified. For time card, we leveraged a category field in order to classify generically what the time card represented. From a conversational perspective to prevent the “big brother is watching you” conversations from happening, I discussed with the delivery teams that deliverable information will be automated based on how we set up the system and the extra time card data point is a necessity to help them. Up to this point, employees would complain that they would have to stay late due to being in meetings all day. As a result of this conversation, a new opportunity surfaced.
With the capturing of when certain deliverables are worked on, we’ll able to do a trend analysis to see which deliverables are being purchased the most by customers. Since time cards are also on a per deliverable basis, we’ll able to calculate our overall costs for the project and over time understand how well or worse we are doing with our profit margins. The new opportunity that rose to the surface was the need to have more up front requirements gathering sessions and more of a hybrid waterfall/agile approach to projects. There was a significant time being spent on meetings and it was only because we would not have a formal requirements session up front. Instead we would meet once or twice a week to do small demos and ask for feedback. In a true agile environment, this works well but not from a services company where the company wants to grow and end projects on time.
After this realization that our delivery process was not as profitable, we revamped the process and statements of work to be more in our favor. The tracking of deliverable costs and time being spent helped us identify where more training is needed in order to anticipate demand with a particular deliverable. It also sparked more interest in what else we can learn from our own data points. As a result, we are ending 2017 with more revenue and more profit by using data to drive our decisions and bring to light issues that can’t be seen during the day to day operations.