Capacity planning for business IT Systems

Capacity planning is a critical part of all Information Technology (IT) environments. It ensures that the number of servers, licenses, physical memory, bandwidth, disk space, room space, etc is sized properly for the maximum return on investment. This ensures that the user experience is positive, while ensuring that unused capacity is not being paid for and managed without a valid return on investment. Capacity planning is ensuring that the workload for a given environment is properly understood and mapped to create a link between a specific number of users and the amount of infrastructure needed to handle those users’ applications. That information is then laid out on a calendar to ensure that the load over time is understood so that capacity can be added and removed as necessary, without a negative impact on user experience.

This document is meant to serve as a guide to what information to consider when beginning the process of capacity planning within your environment. The purpose is to list the most common considerations and strategies for ensuring your capacity plan is an adequate model for infrastructure growth. First, let’s cover some terms and concepts that are important to understanding capacity planning:

Types of Capacity – Capacity is a very broad term, and within the realm of IT there are a variety of places that need to be considered when evaluating current and future capacity needs. While these are separate areas within the same context, each of them directly affects each other. The most common areas of focus for capacity planning are compute power (CPU speed and quantity), memory capacity (both RAM and hard disk), bandwidth (both within a single server and between devices), space (data center, office and storage facilities), data center (power and cooling), and human capitol (staff and contractors for operating the environment, and the relevant skills they posses).

365-day Calendar – Every business has highs and lows in terms of capacity needs. These can vary from month to month, and as often as hourly within the same day. As part of any long term capacity plan, a long-term calendar is needed to show the highs and lows in capacity needs. This should incorporate in holidays that affect the load on the environment, the needs of the business for reporting and trending and any audit needs based on industry specific rules.

User Load relative to Capacity – This is a formal mapping of a specific user load, to a defined amount of capacity with constraints around user response time, availability and user experience. This is the building block for a corporate wide capacity plan and enables staff to understand how much capacity must be added based on user growth. Most organizations will use their Service Level Agreements (SLAs) for setting this relationship.

The process to developing a capacity plan can be long and involve many steps depending on the complexity of the environment, dynamic nature of the work load, and the type of software being using. These are the most common steps (in no particular order) for information gathering as part of developing this capacity plan:

Load Testing – This is the process of testing specific user loads on a known capacity of hardware. These, when done multiple times on varying configurations can develop a capacity model for how many users a set of hardware can support at maximum without performance degradation.

Review of similar environments/workloads – This step is to ensure that knowledge gained within the industry, in similar environments is applied to your capacity plan and your specific environment. This step is not meant to assume some other workload is identical to yours, it is probably not, but there probably are similar workloads that can provide guidance on what to test in the Load Testing phase and what models need to be developed to properly plan capacity.

Trial and Error – A large part of load testing is trial and error. Many environments are simply too large to fully test in a development or test environment. This trial and error can be done in a strategic manner, testing types of capacity needs that are the most likely to be impacted by large or abnormal loads.

SLAs – This is the process of documenting what contractual requirements are in place for ensuring the users get the level of availability, uptime, and performance they expect and have paid for with the service.

The above steps are part of the technical process to developing a capacity plan that is unique to your environment and its needs. These, in addition to carefully documenting when and how to increase capacity can ensure that when the environment hits pre-set triggers, capacity can be added easily, ensuring a consistent user experience.

Capacity planning is ensuring that a clearly defined user experience can be mapped to a specific amount of infrastructure to support that experience. This plan should include not only what increments capacity can be added in, but also what triggers cause that capacity increase to occur. This plan, when associated with a calendar of business needs, trends and holidays can ensure the proactive growth of the environment and a consistent user experience, without having excess capacity that is costing the firm money and not being fully utilized.

Remote Team Dynamics

In recent years companies have increased the speed at which they downsized offices and subsequently hired more staff "working remote." "Working remote" can include a variety of alternative working arrangements, but is most commonly characterized by staff that work primarily from their home, or the customer location. This has created many teams that the staff are distributed across the country and the world. These remote employees typically have the freedom to work the hours they are most productive, as well as at the location they are most comfortable at, this could include coworking spaces, coffee shops or parts.

One significant change as a team becomes more distributed and remote is that communication channels and patterns must evolve to ensure staff feel the same level of connection that they would if they worked in a traditional office setting. Communication models must adapt to ensure that staff not only feel connected to their team and manager, but that they have effective methods to reach out to their team for discussions, advise and coordination.

I have worked in a variety of roles where my manager and I were in different states, as well as managed teams spread out as far as Australia, while I was based in Texas. This presented a unique challenge in ensuring that all team members had the same information and capabilities to do their job, regardless of their specific locations or timezones. Below are a few of the most successful methods I have found for managing a team that is distributed:

Weekly Team Meetings

The primary method for team communication, pass down and discussion should be a weekly call. This provides a known, consistent forum for the team to discuss changes within the team, within the company and pass down information from management to the team. The focus of the call should be kept on items and topics that are relevant to the majority of the team, sideline discussions should be scheduled at a different time to discuss topics in detail that do not interest or affect the entire group. Regular team calls are a great opportunity to foster team trust. These calls provide a place for team members to share their knowledge and experience as well as allow for open communication on issues that need a second opinion or escalation.

The time of the day that these calls are held is critical to ensuring maximum participation and limiting the impact of the call on the regular work of the team. For teams that are spread across timezones it is beneficial to hold calls at alternating times, either presenting the information twice, or to ensure that if one timezone must be up for a very early call, they do no have to make that sacrifice every week, but other regions have calls at off times periodically as well. Another option is to record the calls so that folks can listen to them at a more convenient time.

An agenda for the call should always be sent ahead of time, this will allow people to prepare for the call. An agenda can also be used to set time limits for various topics to ensure that one topic does not unexpectedly consume the entire schedule time for the call.

Finally, meeting notes should be provided after each call. These reinforce any policies stated to the team and allow the staff a reference to refer too later should they forget what was said or decided on the call. These meeting notes can also serve as the official record for any decisions that require review and approval by the team or management.

Roundtable

Every call should contain a roundtable, this provides all team members a brief period to share lessons learned that impact the rest of the team, and allow folks to understand what their peers are working on and may be able to collaborate on.

Each person's time should be limited so that they may mention one highlight and one lowlight of the week. The purpose is to share lessons learns with the team so that best practices can be shared across the organization.

Alternative Team Communication

In addition to a regular team call, there are several other methods that can be used for communicating with the team and building strong bonds between members, regardless of location.

Team Discussion List - An email distribution list should be available for the members of the remote team to communicate on topics that would normally warrant a hallway conversation. This could be technical discussions, product discussions or questions posed to the team about a customer or product. This forum provides the team a known path for team communication and input.

Team Watercooler List - One item that gets missed a lot with remote teams is the loss of hallway discussions on personal issues or announcements. A separate distribution list should be available to the team for topic discussion that is not immediately applicable to the company, but allows employees on the team to get to know each other better and share good news from their personal lives. This allows a name and personality to be shared for each member of the team.

Remote teams are a new challenge that companies are beginning to experience as more and more staff work from home or other alternative working arrangements. By having regular communication with the team, it allows these staff that are separated to keep in close contact, develop a trust for one another and ensure all team members have quick paths for discussion with the team. Ensuing communication flows regularly ensures that these remote employees feel connected to the team and have the information they need to be successful in their roles at the company.

Defining Seniority in IT

Seniority within Information Technology (IT) departments has always been a hard thing to define. The technologies in use shift so rapidly and people move jobs quite often; that determining who is the most Senior person on a team is often not as simple as who has been there the longest or who has worked in the field the longest.

Seniority in the sense of this posting is having the position and experience that the fellow members of your team go to you when they have questions, need advice or otherwise need a second opinion on what they are working on. Seniority is also defining the person that your managers are most likely to go to when they need direction on a project, or need to delegate important work.

Traditionally, companies have often set seniority within a team based primary on time within a given job. This is a less adequate measure in IT because the technology changes so rapidly, a person must keep up with both the technology and what are often called soft skills. These soft skills enable an employee to be more flexible in what they work on, and more dynamic in who they interact with within a company, based on the project and needs of the day.

So, ultimately, what makes you as an employee more senior within your team and subsequently more valuable to the organization?

When positioning the more senior staff up with the lower experienced team members, it is a balance of multiple skills and experience types. One does not necessarily replace another, and a truly Senior member of any team must posses all the following skills at a minimum, with an emphasis on some more then others based on the job role:

• Contributions (Time, Company Goals, Knowledge) - Contributions are the most important part to establishing a position as a Senior member of an IT team. Contributions can be technical in nature, time or knowledge, but all show other members of the team both your dedication, capabilities, and commitment to the future success of the company.
• Experience (Current Technologies, Past Technologies) - Experience with a wide range of technologies and hardware will enable you to make informed decisions and suggestions on future direction and architectures. A wealth of knowledge and hands-on experience will ensure that no matter the problem, you will have experience in how to approach it, even if the specific technology is a new one.
• Understanding of the existing IT Infrastructure - A solid understanding of any existing IT infrastructure will enable you to fully understand legacy burdens when making future planning decisions. It also enables you to understand where the company has been and what has been tried so that if something worked or did not, that can properly be taken into account on future solutions.
• Understanding of the business problem to be solved by IT - Information Technology (IT) is not the primary, driving factor for the majority of businesses. The majority of the companies out there only use IT as a way to meet their primary market more effectively. The most senior staff in IT must understand not only the IT aspect, but the technology and business behind the companies primary market. This ensures that IT is properly aligned and working towards the larger company-wide goals.
• Ability to interact with varying levels of staff and management - Interacting with various levels of staff and management within a company is an important skill. It shows that you not only understand the challenges of each level, but you understand what types and details of communication need to be understood at each level. The proper level of detail and big-picture at each level of communication can ensure quick decision making and solid support from executive management when escalations are necessary.
• Understanding of the company direction - Having a full understanding of a companies long term goals and direction allow IT staff to ensure that suggestions, plans and comments will not become obsolete early in the project life cycle. By showing your managers that you understand the direction, allows you to put the companies best interests first and work towards hitting those goals.
• Time Management - Time management is your ability to prioritize projects based on deliverable dates and ensure that appropriate forward progress is made on all projects to meet the appropriate targets for delivery. Time management shows senior leaders at the company that you understand the complexities of juggling many projects and can compensate as unexpected items come your way.
• Project Management - Project Management is your ability to manage not only your tasks and deliverables, but the dependencies between them and the work of other staff. This type of leadership enables you to work with larger, more complex teams, as well as provide status updates to management on project progression.
• Knowledge Transfer (Mentoring) - This is your ability to assist other staff in developing, both company specific knowledge, as well as industry knowledge. The goal in this category should be to develop into a staff member that others are comfortable speaking with for advise and input, knowing that you can provide a unique, relevant insight for them.
  

Now - the big question - "What about my salary, how does that relate?" - Salary is a difficult subject for some folks. Some people prefer to discuss salary as a very private matter, others feel it is a public topic for discussion. Regardless of a person's choice, their salary is a reflection of the value a company sees in them. If a company is willing to provide a higher salary, they expect a higher level of return. The more traits you posses from the above list and the higher level of development of those traits will translate into your ability to provide more value to your employer.

I hope this has provided some insight into how staff are defined as Senior within IT. Ultimately, it should be your goal to develop the proper balance of the skills listed above, based on your job role. The more experience you can gain in each area and the more expertise, the wider a range of jobs you can hold and staff you can interact with. That flexibility will create value for the company you work for and put yourself at the top of your peers.

Risk Workshops

Risk workshops are an important part of managing risk for all projects. They are typically done at the beginning of a project and any time a major change is made to the requirements or acceptance documents for the project. Risk workshops are brainstorming sessions to develop a list of risks for a project and determine the factors associated with those risks so that they can be mitigated.

Throughout this posting I use the word project a lot. In this context, project is a defined set of activities with a given beginning and end. Projects are common in all companies to take a unit of work and properly manage that unit of work to completion.

A Risk Workshop is a sit-down, face to face, thorough review of all aspects of a project. This commonly includes delivery schedules, acceptance plans, project financials and contracts associated with project delivery. The primary purpose of the risk workshop is to allow both project participants and outside observers to brainstorm all possible risks that could come up and come to agreement on risk level and mitigation strategies.

There are 2 priorities for all risk workshops. All participants should enter with these at the top of their mind as they look for mitigations strategies and project plan changes:

1. Protecting the company from financial loss. This can include penalties for delays or missed features, or having to redo work because of low quality.

2. Delivering the project on-time. All risk mitigation strategies should be worked together with developing the project plan so that estimations are realistic.

The primary deliverable for all risk workshops will be a risk workbook. The most common categories to track for each risk in this workbook are:

1. Risk Number – A unique identifier for the project so that team members can clearly communicate about each individual risk.

2. Raised By – The name of the individual who first brought up the risk. This should be tracked in the event clarification is needed about the risk or impact.

3. Date raised – The date that the risk was first discussed. All notes associated with the risk should have associated dates as well to track the progression of the risk discussions.

4. E/B/C – Engagement/Business/Customer – This category will define the risk type. Engagement is a risk associated with contractual details or the relationship between customer and vendor. Business risks are a risk that a product lifecycle may change or priories shift for a team. Customer risks are associated with delays on the customer side, either because of pre-requisites not being met or changes to the customer's requirements.

5. Description – This is the detailed description of the risk, what it affects and any supporting details to what could trigger it.

6. Risk Cost – This is the monetary cost of correcting the risk should it become a problem during the project. This includes time, facilities, and all associated resources needed to resolve the risk should it become a problem.

7. Risk % - This is the chance that the risk will occur during the project. This is used in pair with the risk cost to determine a risk budget for the project.

8. Mitigation Strategy – This category defines the solution for mitigating the risk. This should define what steps will be taken to lessen the chance of the risk turning into a problem. This could include additional staff on the project, earlier testing, or a chance in architecture.

9. Mitigation Cost – Mitigation cost documents the cost to minimize the chance of a risk occurring. This cost is then compared to the chance of the risk occurring and the cost of the risk occurring to determine if the mitigation cost should be spent, or continuing on the project and managing the risk if it does occur.

10. Risk Owner – The risk owner is the individual that best understands the risk and associated mitigation strategies. This is most commonly the person responsible for monitoring for the risk occurring and documenting the risk mitigation strategies.

11. Risk Trigger – Not all risks will become problems and impact a project. The risk trigger is what defines when the risk does become a problem so that staff can take steps to address the problem.

The first part of any risk workshop is to discuss the objective and purpose with the participants. All risk workshops should begin with a discussion of why the team has come together and what deliverable is expected at the end of the meeting. This deliverable will most often be a risk workbook containing all risks and their associated risk level, potential cost and mitigation strategies. All risk workshops should set time limits to ensure that if a discussion occurs on one risk, the meeting time is not overwhelmed. This time limit is too ensure everyone has a chance to speak on the topic. If consensus is not reached in that time frame, someone delegated by management should be responsible for getting input from all parties and making a decision on the risk level and other details.

I can not remember a project that I have worked on that had zero risk, or a list of zero risks. All projects have some level of risk, and the purpose of a risk workshop is to clearly define them and the plan for avoiding delays because of them. A long list of risks coming out of the risk workshop shows that the team was successful in thinking of possible pitfalls and mitigating them. The purpose of the meeting should not be to have a list of zero risks, that is not the same thing as a zero risk project.

As part of the risk mitigation portion of the risk workshop, there are two primary strategies for handling high risk components of a project:

1. Redesign – Often times a design can be redone to limit, or minimize the risk of a project. The redesign may have other impacts including cost of delivery or schedule impact that must be weighed against the potential risk.

2. Risk Mitigation – Mitigation is the most common strategy for managing risk. This is the early planning of how to handle a risk, should it become a problem. Mitigation often involves having clearly defined paths for escalation to other teams or additional resources available.
   
   

Ultimately the risk workbook will be used to develop a risk budget. This risk budget will be built into the project financials to ensure adequate resources are available to respond to risks if they do become problems, as well as providing funding to cover risk mitigation as necessary.

Risk workshops are a critical component to all successful projects. A risk workshop allows for all interested parties to express any risks they foresee and how to properly plan for and mitigate these risks. Risk workshops should not consume an unlimited amount of time, but should allow everyone to express an opinion to risk levels and allow that to be documented in the risk workbook for the project. Risk workbooks are living documents for the duration of a project and provide a single reference for developing the risk budget and showing mitigation strategies for a project.