The term soft skills seems to imply that these skills are somehow less important than technical skills. In reality, soft skills often separate the technical-level operations person from the senior engineer. Soft skills encompass general business acuity, communications skills, time management, project management, and people management. General business skills include positioning, understanding of organizational finances, risk management, managing customer preference, and thinking strategically.
Communication 101 would tell you that the first step to effective communication is audience analysis. A basic audience analysis consists of answering some simple questions:
- Is your audience technical or non-technical?
- How much do they know about the topic you are trying to communicate?
- How much do they care about the topic?
- What communication mechanism will work best to deliver your message: face-to-face meeting or class, email, social media, internal poster or bulletin board, internal corporate web site?
Before sending one email or updating that web site, think about the answers to these questions. People are inundated with communication from email, voicemail, Twitter, Facebook/Google+, internal web/wikis, text, IM. How can you deliver your message in the best way possible to get the appropriate level of attention for your topic while not overly burden the recipient(s)?
For those who are still communicating with internal customers via email, consider how many emails you send and how long they are.
Here's a hint with email: shorter is better. If you have to include a long technical writeup, consider posting that on an internal wiki/site and including a link for those interested.
Put the most important info at the top of the email. Many people will skim the first few lines to see if an email applies to them. Consider addressing it directly "All users of Macintosh systems" at the top of the email.
If the email requires an action, put that with a deadline in the very first line: "The file cluster will be taken off-line for maintenance at 7:00pm Friday, January 10th. Please save before that time so you do not lose any of your work."
For major outages like the above, it is also good to give more than a week notice for those people who are out of the office for a week or more. You should also consider a followup message closer to the outage to remind people that it is coming up. Forward the original email and repeat the first line as a reminder.
Remember that we all get too much email. If you send an email every day, or even every week, people will start to ignore/filter you. Consider how critical it is to communicate with all of your customers at once. If you limit it to topics that are important to them (outages, new service announcements), they will be more likely to read and respond to your attempts.
- How broadly does this information need to be communicated?
- Is there a sub-section of the population who are the only people who need this?
- Look for avenues to limit how widely you distribute information so you are reaching the intended audience without burdening the rest of the organization..
Communicating with external customers can offer additional challenges. If the external customers are customers of your organization, there is the possibility that your dealings with them could result in a complaint to your upper management.
You can reduce complaints by considering how you communicate with these external customers. When communicating about a service outage, consider timing of the outage, duration, and impact of the outage on these external customers. Are most of your customers in the same time zone? If so, then your maintenance window could be outside of traditional working hours. If your external customers include international people in varying timezones, you will have to choose an outage window that impacts your core customers the least.
Communicate maintenance windows decisions with your line management for communication up the chain. It is best if your management knows that their customers are about to be impacted by operations. You may also need to include a justification for the maintenance: why is it necessary, why did you choose this time window, how did you come up with the duration, what happens if the outage goes beyond the advertised window, how will you communicate to the external customers? All of these pieces of information may not be necessary if you have already established yourself as someone who supports external customers on a regular basis.
In the world of operations, customer complaints are a given. You can't please everyone all the time. Every operations person has dealt with unhappy customers so it is good to develop strong people skills because you are going to need them.
It is important to face customer complaints, not avoid them. Occasionally we have a customer who is a chronic complainer and the operations staff dive under their desks when that person walks in the office. A complaint should be treated as an opportunity to hear a customer's perception of services. Complaints can be turned into opportunities for improvement and can be a path to creating a lasting relationship with your customers.
People are often at their worst when reporting a complaint; emotions are high due to lost data, a service outage, or frustration trying to use technology. Now is not the time for you to get emotional or defensive about your work. Instead of reacting, follow these steps to adeptly manage customer unhappiness and maybe increase customer respect for operations as a whole.
- Listen without judgment
- Rephrase the concern so you can confirm that you understood
- Agree to investigate if it isn't something you can resolve now or you don't have the time.
- Leave the customer with the assurance that you or someone will get back to him/her with a solution or feedback.
- Get back to the customer even if it is to say
- It was a one-off problem and here is why
- We found a problem internally and it is now resolved
- We are improving our processes to reduce the likelihood of it happening again
- Or an explanation that simply provides feedback to the customer.
- And don't forget to thank the customer for taking the time to provide feedback
The reason to close the feedback loop is to show the customer that you did something as a result of the complaint. You may have only asked your supervisor or officemate "was there a problem with the directory server earlier?" but that isn't the point. The customer will hear that you took some action to investigate and potentially resolve the complaint. Maybe you discovered inconsistencies in your internal procedures and by clarifying how to respond to specific issues, you created a better service for everyone. That's a bonus for operations and the customer should know that s/he had a positive impact.
You can try these techniques with chronic complainers. Sometimes all they want is to be heard. Bring in your IT operations management if someone is repeatedly impacting operations with complaints or becomes abusive, This advice stands if you feel like you are trying the techniques above and getting nowhere with the customer. Escalation to the next person in the management chain is a valid procedural step in any of these instances.
Time management is a critical skill for the operations professional. Customer service requests and trouble tickets are up against project work and infrastructure maintenance and enhancements. How does one person prioritize and accomplished?
Recommended reading:
- Tom Limoncelli's book Time Management for System Administrators
- Tom Limoncelli's Time Management Wiki
Tom Limoncelli also teaches a Time Management tutorial at the USENIX LISA conference and sometimes the LOPSA community conferences: Lopsa-East and Cascadia
Project management is a necessary skill for any mid-level operations person. You might start with small projects and work your way up to larger ones.
Be aware that project customers, or stakeholders, will often not know what they truly want from a project or they ask for the moon. Familiarize yourself with the project management triangle (good, cheap, fast: pick two).
Henry Ford is credited with saying about his customers "If I had asked customers what they wanted, they would have said faster horses." Whether or not he said it, it still captures the essence of requirements gathering for operations projects. You, the operations professional, are the technology expert. The stakeholders know they want a certain output or service. They may not know what that looks like or how to achieve it. Your challenge is to extract requirements from the stakeholders then realize that these may not be the real or complete requirements.
Enter project management. Project management should help you to frame the scope, resources, goals, and outcomes for the project. Let's look at two different project management methodologies as they apply to operations.
Waterfall is a hierarchical form of project management that was adapted from other industries for the software development world. In waterfall, think of the phases of a project as a cascading waterfall. Each phase must be completed before moving onto the next phase. The entirety of the project is scoped from beginning to end including milestones and and final deliverables.
Technologies change, requirements change and scoping a large project over a long period of time with what are commonly incomplete requirements or faulty assumptions by stakeholders leads operations down a path of delivering an incomplete or inaccurate solution at the end. Waterfall breaks down in practice because it requires a promise of delivery that may be several years out.
Also, by requiring each phase a project to complete before moving onto the next phase, bugs and issues are often not discovered until late in the project. This causes delays and sometimes large amounts of refactoring or re-architecting to go back and resolve these issues.
Detractors of the waterfall method point to its rigidity and lack of testing during the development phase. One of the issues in operations and development work is that stakeholders may not have a solid grasp of requirements until they see a working prototype, or iterations of working prototypes during the implementation of the product. It is common for stakeholders in a project not to know what technology can deliver until they see it. Many operations teams are moving to Agile methods for several reasons and one of them is because agile development allows stakeholders to see working bits of the product before the end and to modify requirements before it's too late.
Agile is a project management methodology. Agile started in 2001 when a group of software developers created the Agile Manifesto. The Agile Manifesto outlines the 12 principles of agile. Agile is seen most often in the software development world but it has crept into operations because of the obvious benefits over waterfall. Common implementations of Agile include: Scrum, Kanban, and the hybrid Scrumban that was created to meet more operational needs. The idea behind Agile is continuous release or delivery of a product. Instead of creating one big outcome at the end of a project, Agile allows a team to release a partially completed project for stakeholder review and requirements tweaking. Another big benefit of Agile methodologies is the discovery of problems early in the product development cycle when refactoring can be done immediately before the end product is set in a particular architectural direction that would make it costly to change.
Some documented benefits of agile include the following:
- Reduced process overhead
- Improved team and stakeholder communication and collaboration
- Errors and bugs are fixed in development instead of waiting till the product is "complete" to address them.
- Stakeholders see the product as it is shaped and have the ability to adjust requirements during development
- Project teams are empowered
- Can easily be combined with DevOps methodology to improve effectiveness of development-into-operations
- If done well, can increase work output of teams (increased velocity)
- Everyone on the project can easily see where the project stands (e.g. Scrum board or Kanban wall)
One thing to remember when implementing an Agile solution: adapt it to your needs. Each of the following has its own simple framework, but organizations can use some or all of the implementation and even combine Agile methods to achieve success.
Scrum is the more prescriptive of the included methods. Scrum is recognizable by Scrum boards, user stories, timeboxed sprints, cross-functional teams, Scrum Master and Product Manager roles, the burndown chart used for tracking project status, and the Scrum meetings: daily stand-up, and retrospectives.
Some of the limiting factors of Scrum for operational teams include timeboxing and tracking the burndown velocity of the team.
Does all of this terminology seem foreign?
Scrum board - An electronic or physical board that is used to track project status, actions that are in progress, upcoming work, and completed work. A basic Scrum board will have three columns: Todo, In Progress. Done. Items in todo are the up and coming work, items in "In Progress" are currently being worked during this sprint. Done is fairly self explanatory. Assignments can be tracked by sticky note on a white board or via an electronic Scrum board. The Scrum board also has rows. These are referred to as swimlanes. Rows can be labeled with project names and it common to have the very first swimlane titled "unplanned work" for operations tasks that fall on the team.
Electronic Scrum board - Electronic Scrum board software can be great if your team is geographically distributed. All members of the team can see and update the board from remote locations. The downside of electronic versions is getting the team to keep the application open and updated. Burndown can also be computed automatically making it easier for management to see progress.
Physical Scrum board - Often a whiteboard with a grid made of electrical tape. The swimlanes and tasks are marked by sticky notes. The team names can be post-it flags or some other marker. The downsides to a physical board include manual tracking of burndown, stickies falling off the board onto the floor (hint: Buy the Post-It super sticky notes or use tape or magnets), and lastly distributed teams cannot see the board easily. The upside to a physical board is visibility. The board can be placed in a prominent location where the operations staff can see it every day. This makes for easy daily stand-ups. It also allows members of the team to walk up to the board and have conversations with other members of the team about the work in progress.
Sprint - A sprint is a duration of time defined by the team when the work will be done between Scrum meetings. Work is chunked into pieces small enough to fit within the sprint window. A sprint window might be a week, two weeks, four weeks, or whatever length of time seems to fit your team. During the sprint, operations staff focus on the work agreed upon at the beginning of the sprint. Organizations can define how unplanned work will be dealt with during a sprint. Sometimes it is helpful to be able to tell a customer that we can prioritize that project request in two weeks at our next sprint meeting instead of feeling like operations has to drop everything for a last minute request. Sprints are somewhat rigid and can break down with operations because the work doesn't neatly fit within a timeboxed window. The team will also provide time estimates for each task.
Daily Standup - This is a short daily meeting with the team at the Scrum board (virtual or physical). The person in the Scrum master role leads the daily stand-up by asking each team member a few questions:
- What are you working on?
- Are there any impediments?
- Do you need anything to be successful?
Each member of the operations team now knows what is expected of him/her for the day. Sometimes this is bad if the team is also responsible for trouble tickets or responding to reactive work such as service outages.
Burndown - The burndown tracks estimates of time with the actual time spent working on a project's tasks. The resulting chart will show a project approaching 0 as the level of effort needed to complete the project winds down. Teams get better at estimating with experience. Burndown can also show you if a project is taking longer than planned or a head of schedule. Building a burndown chart can involve some Excel foo (or choose your graphing application of choice). It is common to build formulas in excel that will automatically update a pivot chart showing the project tracking. Some burndown charts are very complex and others are simple. Your organization has to decide how fancy to get with this tool.
User stories - In Agile software development, user stories can be feature requests, bugs, or modules the team plans to code for a product release. In operations, user stories can be small or large projects. Smaller projects are usually broken down into smaller more easily digestible pieces otherwise a project can park in a swimlane for an inordinately long time bringing down team morale and potentially impacting productivity. Teams should see positive outcomes and accomplishments across the swimlanes.
Cross-functional teams - In a development environment, a cross-functional team could include developers, testers, management, and operations. The purpose is to introduce DevOps to software development by including roles that have a stake in the project at different levels. In operations, a cross-functional team could include people from systems administration, networking, security, and management.
Kanban is a much less prescriptive Agile implementation. Kanban can be recognized by a similar task board to Scrum but often there are more columns. Kanban's strength is the work in progress (WIP) limit. Kanban doesn't require roles, timeboxing, or burndown tracking like Scrum.
Because there is no timeboxed sprints, work continuously moves across the swimlanes on the Kanban board. Daily stand-ups are critical in Kanban because there isn't a touchpoint at the end of a sprint to review completed work effort. Kanban boards can have several additional columns to assist in the management of this continuous work flow. An example Kanban board may have "Coming soon" "Review" "Available" "In progress" "Acceptance" "Completed." The purpose of these additional columns is to enable teams to pull work into the "In progress" column as they finish other work. The "In progress" column and other columns will have what is called a WIP limit. There are a few schools of thought regarding WIP limits. Each organization must experiment with the WIP limit until a sweet spot is found for operations.
In Kanban for operations, the columns can be varied across teams or organizations. These columns are only provided as an example. Your organization needs to find the Kanban workflow that works best for your team. There are several good resources that explain various ways of configuring a Kanban board. Sticking with the current example, let's review the columns in our example Kanban board so you can understand their purpose.
- Coming soon - these are tasks, projects, or user requests. They are un prioritized and may be big or small.
- Review - These are tasks that are prioritized by management or the team during the daily stand-up. They are put "in the hopper" so to speak as work items that should be reviewed and possibly broken into smaller pieces if they are too large. The downside of too large is similar to Scrum when the user stories were too broad. If an in progress items its in the active queue too long, it takes up a WIP slot and can make it difficult to understand if the team is making progress on that item.
- Available - This item has been reviewed, broken into a reasonable sized task and approved by management or the team to be pulled into the active column at the next opportunity.
- In progress - Similar to Scrum, these are the tasks being worked actively by the team.
- Acceptance - When someone on the team considers a task complete, s/he moves it to this column. Acceptance means it is discussed at the next daily stand-up and possibly accepted as done by the team. Acceptance can also mean stakeholder acceptance. This could also be a testing phase for something that is rolling toward production. If something idles too long in this column, it will hold up other work because of the WIP in progress limits placed on this column.
- Completed - These are tasks that are accepted as completed and put into production.
Work in Progress (WIP) limits WIP limits define the maximum number of tasks that can appear in that column on the Kanban board. The two schools of thought that seem to pervade include:
- 2n-1 - where n = the number of people on the operations team. The reason for this is to enable team members to work together on some tasks but to give enough tasks so team members stay busy.
- n-1 - where n = the number of people on the operations team. The reason for this is to encourage collaboration on the team and not to overwhelm them with too many tasks. If someone on the team completes all of his/her work, that person should be able to pull the next available task from the "Available" column.
What is the risk of having a WIP limit too low or too high? A high WIP limit might mean the team is taking on too much at one time. Each member of the team may get overwhelmed with the amount of work. Consider these are reviewed daily in the stand-up meetings and team members can pull new work from the "Available" column when current work moves to "Acceptance." Also high WIP limits mean that team members are less likely to work together on projects or tasks because each person has his/her own work to complete.A WIP limit that is too low could create a bottleneck, disallowing a team member from pulling new work into the "In Progress" queue because other people on the team have hit the WIP limit with their own work. The WIP limit is a sweet spot that your organization needs to discover through experimentation.
Whenever there is a bottleneck in Kanban, the team can refocus its efforts on the item stuck in the flow in order to unblock progress across the board. WIP limits force this to occur because a column with a WIP limit of 3 on the acceptance column will not allow any tasks to move to that column if there are already 3 items waiting for acceptnaca. It is a way to keep work moving across the board.
Scrumban is a hybrid of the two previously mentioned methodologies. Operations teams seem to embrace Kanban or Scrumban because of the flexibility of re-prioritizing daily and the WIP limits that keep the team from getting overwhelmed.
A Scrumban implemenation would take elements from both Scrum and Kanban. For example, you might decide to define some roles, keep the review and retrospectives, hold the daily standup from Scrum while enforcing WIP limits and implement continuous work flow from Kanban.
DevOps seeks to include the IT operations team as an important stakeholder in the development process. Instead of developers solely coding to meet the stakeholder's requirements on time and on budget, they are also held responsible for how easily it deploys, how few bugs turn up in production, and how well it runs. Basically, how easily can operations support the product once it rolls into production. Instead of bringing operations into the conversation after the product is complete, the DevOps methodology includes operations in the development stream.
Development's view:
- Roll a product out to meet customer specifications within a certain timeframe
- Continuous delivery means recurring change as bugs are fixed and features added
- fast changing environments are needed to support dev
- agility is key
Operation's view:
- supporting the product for customers
- keeping a handle on IT security
- planning for deployment to production state
- changes are slow/incremental
- consistent environments are needed to support operations
- stability is key
In organizations where DevOps is not a priority, development is often viewed as customer-focused by trying to solve problems and deliver solutions while operations is viewed as a barrier to development's mission. By combining these two, often competing mindsets, both sides can be satisfied and the result is a product that potentially has fewer bugs, higher availability, increased security, and a process for improved development over the life of the product that works for both the developers and the operations people.
Some are also talking about implementing a DevOps methodology in pure operations teams. In this scenario the operations team is also Development because they stand up a webserver, provision virtual machines, or code configuration management systems. In this case, operations needs to wear both the development and operations hats by meeting customer needs while also addressing security and supportability of the solution.
A person cannot be a DevOp. You don't hire a DevOp.
What is business acumen? Business acumen a leadership competency simply defined as a general understanding of business principles that leads to an organization's success. We aren't trying to turn every operations person into a senior executive, but development of business acumen as applied to operations can sure help to bridge the gap between your organization's senior leadership and the operations team. Business acumen as applied to operations works on multiple levels. In many organizations, operations is a service unit within the larger organization but it also serves the needs of the organization as a whole. The savvy operations person will look at operations within that context, applying the following skills to appropriately position operations and act with the best interests of the greater organization in mind. This also helps when trying to make your organization DevOps friendly.
Distilling the definition of business acumen for operations yields the following important skillsets: * Understand the role of operations within the context of your organization to correctly position operations. * Think broadly about decisions and act decisively * Support and promote change as needed * Develop basic business skills that allow operations to communicate within the executive suite
Under any of the operations professions, the most fundamental role of the operations person is to deliver services to a set of customers. To build upon this further, the operations person maintains existing IT infrastructures, translates customer requirements into tangible and actionable solutions, assists in the protection of customer information and services, and advises stakeholders on application of technology under existing limitations of time, money, or capabilities.
By thinking of operations as a business unit instead of a forgotten office within the organization, the operations engineer is already thinking at the correct level to assess how to support the needs of the organization.
Understand how your organization competes within its industry. Commercial entities, non-profits, educational institutions, government agencies all measure success in some way. For commerce, it will be sales and profit. For educational institutions, it might be numbers of incoming students and retention rate of students. For a non-profit it might be the number of people willing to give to support the work of the organization and the number of people who use its services.
All of this leads to correct positioning of operations within your organization.
- What are the core competencies of operations and how do they serve the internal business units and the organization as a whole?
- What core competencies are you missing and should develop in order to better support your organization's mission?
The most visible role of Operations is to maintain the status quo. For the system administrator this means maintaining servers and processes such as logging, monitoring, backups, authentication, or naming services. For the network administrator it means maintaining routers, switches, the edge network, gateways, or the relationship with the corporate Internet Service Provider (ISP). A security engineer might be responsible for maintaining a vulnerability scanning capability, incident response policy and processes, intrusion detection systems, firewalls, and a customer security awareness training program. Operations may also be responsible for maintaining access to internal services (e.g. financial systems, corporate content management systems, procurement systems, etc.) that may impact the various business units within the organization. These roles are distinct but there is sometimes overlap between them in smaller organizations where fewer people server in multiple roles.
Operations roles are customer service positions. These careers require a level of customer interaction because the services delivered by the Operations professional must be driven by customer needs. In this case, customer is used to mean the business, organization, or other entity that is employing the Operations professional. Some questions to ask to help the Operations person understand requirements from the customer perspective:
- What is the core mission of this organization?
- How does Operations support, hinder, or allow your organization to innovate for the mission?
- Who are your core customers (internal, external, or both)?
- What does the organization need from the Operations professionals?
- Why should this organization come to these Operations people for this service or solution? (What is the value proposition for Operations within this organization?)?
- How could Operations provide more value: higher level of competitiveness, faster service delivery, stronger security, or other benefit that aligns with the mission?
Translating customer requirements is key to focusing the efforts of Operations. Operations work can be a slippery slope where the professionals are spreading themselves too thin on projects and deliverables that do not serve the organization's mission. One way to focus the efforts of Operations is to answer these questions and to ensure that the Operations organization, whether insourced or outsourced, is delivering services that provide the most value.
Often the Operations professionals in an organization are the people who most completely understand the technical risk to organizational assets from an IT perspective. Senior management within an organization will usually understand risks related to financials, competition, manufacturing, etc. but they often do not understand IT enough to make an informed decision. Operations professionals are the ones with the deep-dive technical expertise required to comprehend risks, threats, vulnerabilities, and countermeasures then translate them into language senior management can understand.
This is another area where the Operations professional is communicating with the organization's leaders to advise on appropriate actions to address IT security where it makes sense for the organization.
Areas where organizations need the Operations professional to advice on IT security could include threats to data from internal and external sources, hardware failure, site availability or resilience, data preservation, and information integrity. Again, these areas are dependent on the organization's mission.
For example: an ecommerce organization will most likely want strong site availability and protection of customer personal information. The Operations professionals might build a site with high resilience and availability including use of Content Delivery Networks (CDNs), strong encryption not only for the ecommerce session but also data at rest, role-based access for internal employees accessing customer information to reduce access to only those people who need access to that information. Organizational leaders often do not understand how these solutions are implemented so it is up to the Operations professional to communicate the threat, solution, cost, impact to the organization of implementing the solution.
The Operations professional who advises an organization must also consider limitations that impact the potential solution. Cost, timing, expertise within the organization, available time of the people who would implement the solution, or IT security issues may be considerations. For example, decision makers within the organization will need to know what is possible and for what cost so they can make the decision how to spend the organization's money. Good, fast, or cheap (pick two): it may be the Operations professional's responsibility to explain this concept from an IT perspective.
These people can look at a problem from the viewpoint of other people and business units within the organization. Instead of insular thinking, they come at a problem with a broad-minded perspective. How do decisions impact other areas of the organization and, alternatively, how does the organization view this particular issue? Those with strong acuity for business will see the big picture and be able to understand the implications of a decision on more than just operations.
In some cases it may not be a problem, but an opportunity that injects potential life into an organization or recalibrates it. Business leaders, stakeholders, customers or whatever you call them often don't understand what technology can do for them. Operations should understand the organization well enough to see where technology can support innovation. This leads into change as a constant.
What would it take to make this happen? What are the missing ingredients for success?
The operations world changes rapidly, more rapidly than other sectors. Operations people cannot afford to to a specific operating environment, hardware platform, or technical solution because the industry has already started moving toward the next innovation.
Basic business skills could be as simple as learning to use Excel to build a basic budget or navigating internal business systems and such as procurement, capital expenditures (CapEx), contracts. Some skills are the same everywhere (e.g. Excel) and some require study of the internal organization (e.g. procurement). Understanding CapEx means being able to compute depreciation but also understanding the CapEx calendar within your organization, how that money is spent, and how to request capital spending using your organization's process.
A basic knowledge of Excel includes formulas, formatting for readability, using multiple worksheets, and importing external data, More advanced Excel knowledge includes use of macros, pivot tables and pivot charts.
Some operations folks use other Excel-like programs such as OpenOffice or LibreOffice spreadsheet programs. Use caution when using something that your senior leaders do not use. If your whole organization has adopted LibreOffice as the standard spreadsheet application, that works. The problem occurs when your boss wants to share your spreadsheet with some of the organization's senior leaders and the file format doesn't translate exactly or the file is unreadable to them. In this case, you are trying to bridge the gap between operations and the executive suite, so try to use their tools when possible to avoid small issues that can cause frustration to the people you are trying to persuade.
Building a basic budget requires institutional knowledge. How is employee labor computed? You need to understand what income you have and where it comes from? Are any employees billable to other projects? You may have a flat budgetary structure with a single cost center for all labor or you may have multiple cost centers. Is there any income that has special restrictions? How do you purchase things such as parts, services, software, contractor services? Do you have to account for overages or money not spent at the end of the fiscal year?
Generally organizations have financial people who can provide reports for various cost centers. If operations fits neatly within one or more cost centers, these reports can help you build your budget. If operations is combined with other projects or business units, then the work of separating operation's budget becomes a bit more complex. Starting with these reports is a good first step.
To really understand how these reports work, you should understand how operations is paid and how it spends within the organization.
Where does operation's base funding originate?
- Is Operations billable or do they have constant funding from year-to-year?
- Does someone need to request this money or is it always there?
- How are pay increases funded?
- Is there only one source of money or are there multiple income streams?
Does everything come out of one cost center or are there multiple cost centers?
- If multiple, are they broken down by project, type of expenditure (labor, contractors, services, supplies)?
Is any of the money special?
- Does it expire
- Does it come with strings/hooks to specific projects or billables?
- How are employee salaries computed to include benefits and overhead?
- How are contractors paid?
- Are there special rules for obligations? In some organizations, some kinds of money must be allocated up front and cannot be reclaimed even if not spent until after the contract or service has completed or the fiscal year has ended.
- How do operational purchases work within your organization (parts, services, software, training, travel, supplies)? Who pays for these purchases? Who tracks these expenses?
- Does your organization have a CapEx process and where does that money originate? Does depreciation impact your budget?
- Are there any hidden costs?
- Service fees from internal organizations?
Answering these questions and looking at reports from within should give you most of the answers you need. You may have to implement your own tracking to get some answers if they aren't easily identified in the reports.
Why would any sane operations person want to go through all of this to assemble a budget:
- Operations is understaffed and wants to ask senior management to hire more people
- There has been staff turnover and operations needs to fill those positions. How much is available and what opportunities exist to do something different?
- Senior management is asking hard questions about the operations budget (e.g. why do we spend so much on operations, where does the money go?).
- You want to bring in a student or contractor to help with some short-term work but you need to demonstrate that operations is spending wisely in order to get approval for an increase.
Just putting numbers in a spreadsheet isn't budgeting. What do the numbers tell you? Are you spending too much on senior people? Equipment? Vendor maintenance? Where is the majority of your spending (commonly it is labor)? An easy to present budget can also help you to understand if operations is well managed.
Take that same view of the budget that gave you visibility into operations and use it to support a request or a claim to senior management.
Let's take the example of a senior person leaving the organization. Operations needs to fill that slot with a new person to avoid getting overwhelmed.
- Does this vacant position present an opportunity?
- Does operations need to hire someone with specialized experience in a new area?
- Could operations benefit from hiring two junior level people using the same salary slot as the former senior person? Does that work mathematically within your organization's hiring rules?
- Could you reduce the overall cost of operations to help the organization by hiring one junior person and growing that person?
- Could you hire a junior person and use the remaining money to refresh hardware or invest in a new technology to help the organization?
You can probably see how you could make some of these arguments mathematically in a spreadsheet. The part that is missing is the "why" and that's where the impact comes in. Senior management may believe that operations needs to reduce overall costs. This is when you need non-numerical supporting evidence to persuade management that operations does need to hire a specialist or make the case for an apprentice that would achieve a cost savings but would reduce capabilities until the person came up to speed within the operations team. Budget decisions have consequences, make sure those impacts are clearly illustrated within the numbers but also be prepared to explain the non-monetary impacts. This includes risks to the organization such as reduction in capabilities.
When preparing for a big budget presentation where you are asking for a decision that will impact operations, consider the following supporting strategies:
- Enlist customer support. Customers are asking for improved capabilities, better response, new technology. How can they provide input to management that operations needs more or different resources to serve them better?
- Find out if there are any new initiatives within the organization that would rely on specific expertise or additional operations resources. This demonstrates a tangible need (e.g. Project X will require 50% of someone from operations to implement their technical plan).
Using these additional supports requires knowing your organization and having a good relationship with your customers. Ideally customers come to operations in the planning stages of new projects in order to get feedback on potential technology issues before they begin work. That makes this step a bit easier. If not, then you can begin your reconnaissance by talking to project leaders or middle management within the organization.
When researching organizational needs, start with some basic questions:
- Are you planning anything new in the next year?
- What projects is your group starting?
- What technologies are we not using that you think would make your unit more productive?
- Does operations provide the right level of support to your division?
Exercise:
Now, the budget you build should directly respond to the problem or issue you are trying to address. Choose a scenario from above or make up your own.
- How would you build a basic budget to persuade senior management on your issue?
- What would be important to highlight?
- What non-monetary supporting information would help your cause?
The cost benefit analysis, or CBA, provides senior management with concise proof that you have done your homework when you propose a solution.
The first step in the CBA process is to know your audience. The higher up the organizational chain you go, the less detail you should need. Before you present a CBA to your management, you are going to have to prove to yourself that your solution is the best one.
Before you can detail the cost of your solution, you need to know what you are spending today without it. What is the cost of not doing anything? This is where the benefits of performing your solution would need to outweigh the status quo.
Everything in a CBA should be represented in the same units. The units used are most often money. So you need to be able to consider benefits to your solution in terms of savings, efficiency, increased income to the organization.
Cost should include anything that explicitly adds to the total cost of the solution:
- employee labor
- contractor costs
- maintenance fees
- up-front costs and licensing
- hardware
- depreciation
- facilities costs (outfitting a space)
- provisioning or migration costs
- networking
Benefits should include anything that is an outcome of your solution:
- increased productivity
- increased organization efficiency
- increased income to the organization
- increased capabilities that enhance the organization in another way
Might give an example here. Need to write more explaining how to assemble the pieces.
Exercise
Put together a CBA for a recent project or task you worked on or encountered:
- How would you estimate costs that are not known?
- How do you monetize benefits that are not explicitly monetary?
- What does the result tell you?
- How could you sell this idea to non-technical people using your CBA?
The Capital expenditure (CapEx) process is used by organizations to purchase assets that have value across multiple tax years. In operations CapEx usually means new equipment or equipment that extends the useful life of existing equipment beyond the existing tax year.
CapEx allows an organization to depreciate an asset over the estimated useful lifespan of that asset. How is this valuable? Well, on the organization's balance sheet, only part of the total expense is counted for a specific tax year. The amount of the expense depends on the type of depreciation used.
With straight line depreciation, assets are depreciated at an equal amount each year. So a piece of equipment with an estimated useful lifespan of 4 years would be depreciated 25% per year on the organization's expense sheet.
Accelerated depreciation usually frontloads the depreciation costs. This method may more accurately reflect the value of equipment because there is a greater depreciation at the beginning of the cycle. An example of accelerated deprecation might require a piece of equipment to be depreciated over 4 years at a rate of 40 percent per year. Obviously you would have a greater expense in the first year because you calculate 40% of the total value of the asset. In the second year, you compute 40% of the remaining value, and so on until you get to the fourth year or $0.
An analogy to help explain Accelerated depreciation might be the purchase of a new car. The car depreciates the moment you drive it off the lot. Even if you were to sell the car soon after purchasing it, the car has already sigificantly decreased in value.
This skill goes hand-in-hand with budget but it is also an excellent standalone skill. Operations deals with complex implementation of technology whether or not you realize it. To the non-technical person, the architectural diagram on your whiteboard looks like a Rube Goldberg machine.
The further up the management chain you go, the more distilled your information should get. Senior leaders do not usually need or want deep-dive technical detail. When presenting a complex solution, it is fine to have one diagram that is completely unintelligible to them as long as it is only used to to demonstrate that operations did more than throw a blade in a rack and spin it up to achieve the solution. The most important part of the presentation is the part where you answer the questions in the heads of your senior leaders even before they ask them.
What are their questions?
- What are we trying to accomplish?
- What do we do today and how is this better?
- How do we know this is the best solution?
- Do we have the right people to make it happen?
- How much will it cost?
- How long will it take?
- What is the benefit if we do it?
- What is the risk if we don't do it?
- How do we know if it worked?
Exercise
Take an idea you have and use the questions above to try to build a case for senior management to fund this idea.
Below are some specific examples to demonstrate the importance of soft skills in operations. In each example, soft skills closed the deal because they enabled the operations person to see the situation from other perspectives and communicate the needs of operations in terms of the organization as a whole.
- Runbooks? SOP? (cparedes: might be worthwhile even though we want to automate SOP's away as much as possible - what should we check at 2 AM? What do folks typically do in this situation if automation fails?)
- Architecture and design (cparedes: also maybe talk about why we choose that design - what problems did we try to solve? Why is this a good solution?) How to manage documentation
Anecdote At one job we had a single network engineer. He had a habit of walking up to a whiteboard to explain something to the systems folks. He would proceed to draw what we considered a hyper-complex-looking diagram showing the current or future state of some networking solution. We could never keep his configurations in our heads like he did and he wasn't always around when we had a question. One of us figured out that we should take a picture of the whiteboard after he finished drawing. These pictures went into the operations wiki. They weren't beautiful but they saved us time when we could easily refer back to the pictures we took.
Diagrams don't always have to be professional visio-quality to count as documentation.
Functional diagrams
Technical diagrams