I'm a new manager of the business intelligence (BI) team whose mission is to effectively provide accurate information to the campus in order to support data-driven decision making. I've discovered three vital organizational elements:
- Clear and complete documentation
- Consistent review and improvement of business processes
- Effective role modeling
If any one of these elements is missing, the effectiveness of the team is at risk of being compromised.
Effective role modeling may well be the most important of the three elements. Improvements in documentation and business processes without effective leadership may still leave the organization short of delivering desired results. A simple online search on the characteristics of an effective leader yields plenty of articles, books, and videos. Many of them relate to the human side of team leadership—communication, respect, integrity, listening, collaboration, etc. These are all important in leading a successful team whose members are happy in their jobs. However, one can excel in each of those traits and still not lead a successful team. The full picture of team leadership includes the work side of the job in addition to the human aspects. Team members need to know what tasks their jobs require, understand how those tasks are expected to be accomplished, and plan for when the tasks are to be completed.
To ensure my team is effective, I work to incorporate all aspects of effective team leadership. I work hard to communicate with respect, listen attentively and actively, and discuss our shared responsibilities as a team. I also strive in my leadership work life to be consistent, accurate, and efficient. I want my team and the colleagues with whom I work to be able to function in the same way.
The Beginning
Our BI team became one unit within the last year. Prior to that there were two people working on BI at the College of Charleston who were in two different departments and worked fairly separately on very different parts of the BI process. An out-of-town move prompted uniting the two disparate positions into a single team. We were then able to expand the team by filling some vacant positions, which were filled by people not familiar with the college's business processes or with the tools we use and how we use them.
Over the seven-plus years I have been at the College of Charleston, I had documented various process components that were required, but most of my business processes and troubleshooting tasks were in my head, or at the very most, outlined in electronic or hand-written notes. In addition, there were a few semidocumented business processes and copies of code of the customizations we had implemented. Thus, we are a new department with new employees and new roles, and little business process documentation describing how to successfully accomplish our tasks.
The Transition to Documentation
As the team has grown, we have had to review existing business processes that had no documentation. When I asked others about "onboarding" new employees, for example, no one was able to provide an up-to-date or complete document for that process. So I created one for the BI team. It includes everything from the security needed for the various software to the keys for the doors to the drives the new hires will need to map on their computers.
Training new team members on how our team does its job with no existing documentation has given me the opportunity to begin creating the documents we need. It gives the new employees the guidance needed and me the comfort of knowing the proper foundation is in place. It also has given us the chance to enhance some of our business processes, automating some and streamlining others. This is the first thorough review of our existing business processes since I have been at the college, and I am eager to do more.
As a new manager, I learned that my team members sometimes approach things differently from how I approach them. They each come from different teams with different knowledge and experiences. I have also learned that there is tremendous value in empowering them to apply their perspectives. One significant benefit is that we take my business processes and turn them into our business processes, which is a key component of a successful team. The team can institute changes to make the business processes more efficient or accurate and adapt them as our needs, tools, or environment change. They can update the documents when what I created does not include enough detail for them or when they have a more effective way of accomplishing the specific goal. Microsoft Word's File/Save As offers some version control, which is often used and relied on. Starting from an existing documented business process when minor changes are needed is beneficial, rather than needing to start from scratch. By empowering the team members to make these changes, I hope to deepen their commitment to their role on the BI team.
We are also in the process of filling another vacancy. We have found that there was little documentation and no comprehensive list of the customizations that were made. After a year, I am still adding to the list and trying to find all of the triggers, packages, and functions that were created or modified. There is no documentation defining why some customizations were created in a College of Charleston schema, while others were created in the delivered schema. The new team member will have the opportunity to ensure consistency in the business process, accuracy in the data returned, and efficiency related to the performance of the queries, as well as to document any reason for anomalies that may be necessary.
I am not the first to struggle due to a lack of thorough documentation. Lack of documentation required three months' work for S R Balasubramanian and, to prevent such a situation in the future, whenever he left a job, he wrote a "handing over report" for management.1 This leave-behind document includes the status of work, matters needing attention in the next several months, important notes from vendors, and other information management or the next person may need to have.
Review and Improvement of Processes
Our IT division is implementing a new service management tool. This means we are creating new tickets, services, workflows, and knowledge-base documents. The BI team is eager for this opportunity for two primary reasons: to make our operational duties more efficient and to be able to easily document our work and accomplishments. It also gives us the opportunity to retool old business processes requiring manual work that can now be automated with the new features offered by the new tool.
The BI team already has some documentation that we can easily update for the new tool, but numerous processes were not documented at all. Therefore, we have a lot of work to do to get ready to take full advantage of the new system. This review also gives us the opportunity to put more control in the hands of our end users by providing them with the steps we use to solve some of their issues. For example, when downloading a file into Excel, the pop-up blocker in Internet Explorer with the default settings keeps the download box from opening. By documenting things such as which Internet Explorer settings to change to facilitate use of our reporting tool, we can create new knowledge-base articles. These articles should help our BI community help themselves without having to put in a ticket and wait for a response from the help desk or our team. Empowering the user is a key success factor for our work.
It is critical that we have BI metrics for the BI team. Maintaining in one place all of the work we do on our team will ensure that we are consistently and accurately reporting our work, as well as successfully completing it. This will help not only with our IT scorecard but also with personnel performance evaluations at the end of each year. Things such as tracking long running queries, peak time for usage, and commonly requested reports create the opportunity for our team to focus on what is important for decision makers at the college. These measures will also facilitate finding issues that commonly arise and figuring out how best to address them, whether that is writing a new knowledge-base article for users, rewriting a complex query for efficiency, or improving system performance oversight on the server.
We anticipate needing a six-month review of everything for which we use the new service management tool. Six months will give the team time to become more familiar with the tool and how it works. Reviewing our existing business process will ensure that we are doing our work in the most efficient way, utilizing the tool to the best of our ability for our benefit and that of our BI community, and that the new tool is helping us be consistent in our work. We will be able to ask, What are we doing that we now know the tool can do for us? We may find we have nothing to change, or slight improvements to some processes are required, or significant changes should be made to specific areas. Whatever the results, we plan on reviewing our processes every three to six months.
I found a documentation scheme posted at Rhyous to be particularly useful, but there are many other options as well. Enter the keyword "documentation" in the EDUCAUSE Library, for example, and you'll find numerous documentation taxonomies used by college and university colleagues around the country. Adapt one or more to your specific requirements. For my purposes, the eight types of technical documentation suggested by Rhyous (aka J. Abram Barneck) seem to work well.2 They are:
- Step-by-step walk-throughs
- Product features
- Troubleshooting guides
- Knowledge base/FAQ/forums
- Backups of code/API/SDK
- Internal development
- Customer use cases
- Marketing
Each is important to the success of our team. Initially, the step-by-step walk-through, backups of code/API/SDK, and the troubleshooting guides are the most helpful. However, a robust knowledge base/FAQ/forums area and use cases will be tremendously helpful to our team, as well as the BI community on campus. We are working on developing knowledge-base articles to help those on campus who gain value from insights the BI reports provide, along with the authors across campus. Additionally, we want to be able to create a user community that shares in the successes its members have achieved through use of our reporting tool, whether that is streamlining a business process, relating processes they use to make report authoring easier, or simply noting how to correctly pull a specific data set that is complex in nature.
Conclusion
In all that we do in BI, our main goals are consistency, accuracy, and efficiency. Sometimes this requires some tasks that are not particularly exciting or fun to complete but will make all of our jobs more efficient in the long run. The documentation of business processes will benefit our team, as well as our BI community, and even other teams in the IT department. Doing the documentation ensures we fully understand what is actually going on behind the scenes and gives us a better understanding of our users' perspectives and needs. While changing processes too often can cause confusion between the new way and the old way, an intentional review on a scheduled basis can only benefit the health of the processes and the members of the BI team. Creating and documenting streamlined business processes is important, but too much processes reworking can result in reduced work productivity if we focus on the documentation instead of completing our tasks. It is important to find the right balance.
It is also important to me as a new manager that I be a role model for my team. By creating clear and complete documentation of our business processes, together with review and continual improvement, I model good work for my team. And by tackling the problems we face head on, setting clear expectations, and listening to my team and empowering them to improve processes, I also believe I demonstrate good leadership.
Notes
- SR Balasubramanian, "Importance of Documentation" [http://itknowledgeexchange.techtarget.com/information-technology-management/importance-of-documentation/], TechTarget, April 23, 2012.
- Rhyous,"The 8 Types of Technical Documentation and Why Each Is Important," July 21, 2011.
Mary Person is business intelligence architect and manager of information technology at the College of Charleston. She earned a BS in business administration with an emphasis in finance magna cum laude and an MBA with an emphasis in accounting, both from Charleston Southern University.
© 2016 Mary Person. This EDUCAUSE Review blog is licensed under Creative Commons BY-NC-ND 4.0.