In my last blog entry, I discussed why you need a solid demand management process. Demand is what others are asking you to do. It is your “to-do” list or backlog of activities. From this list or backlog, you must be able to select the right work. The other part of what you do for a living is executing the work: doing work right. Therefore, “right work” (what is best to do next) vs. “work right” (what people, processes, or tools will be employed to do the work in the most effective way).
The world of “right work” (demand) and “work right” (ways to work) can be divided into three main categories: operations, projects, and initiatives. That is, all demand and work that a company may have will likely fall into one of these categories. Hence, I chose to name this article: Doing Work Right – Part 1: Operations. I will focus this article on the approaches and processes for “work right” in the operations category. My next upcoming blog articles will address the other two categories: Doing Work Right – Part 2: Projects and Doing Work Right – Part 3: Initiatives. Keep an eye out for those upcoming articles.
Is There a Right Way?
Of course, there is no one way or right way to do anything, I suppose. But I do like the phraseology of “right work” vs. “work right.” It helps to quickly differentiate between demand and work. So, what I mean by “work right” is really employing the optimal people and practices to get the job done in the most efficient and productive way while adding value to the business. Now, to do that you need a process. But before we jump into that, let’s level set on what operations is so we are on the same page.
Let me further refine the term operations to provide context for this article. Operations, at a high level, refer to:
- Day to day functions of the business.
- Keeping the lights on.
- Like a utility company – you just expect it to run.
- Typically, smaller units of work.
- Always running – sometimes even 7 by 24.
Regarding the IT world, let’s look at two operations viewpoints: customer facing (those operational activities that the customer interrelates with) and internal facing (those operational activities the customer does not see or touch but are necessary to run the business.)
Some examples of customer-facing operational activities are:
- Help Desk – Help Desk or call center duties are sometimes split between an IT Applications Help Desk and an IT Operations Help Desk. Usually the ops help desk is what they call level 1 and the application or system help desk is level 2.
- ID or access management – People need access to their applications, or specific roles and permissions. Sometimes, this is managed centrally by operations.
- Production or “hot” fixes – Something is broke, and it must be fixed ASAP.
- Escalation – You need a clear escalation path when an issue is determined to know who to inform and how to move up the org chart. You may need approvals for more resources or access to subject matter experts that are beyond your pay grade, so you would need to escalate the issue to get the necessary approvals. The ops role is always looking to find, fix, and inform.
- Small updates/features – These are code changes that are small and are handled directly by the ops team. Now you need to decide what “small” means, that is, level of effort. For example, anything less than 16 hours may be considered small in your group.
- Application subject matter experts also known as SMEs – Many times, your issues may be simply handled by a SME or domain expert by talking or walking the customer through the issue to resolution.
- Off-the-shelf software installation and configuration for business applications support – Many times off the shelf software or cloud-based software needs to be configured and set up to support the customers. Many times, an operations group will perform this function.
Here are some examples of internal-facing operational activities:
- Integration with business partners, customers, and other entities (ex., FTP, EDI, e-commerce connections for ordering, copying data between servers, setting up API end points, etc.) – Every company has business partners either on the supply chain side or the customer side to work with electronically.
- Job-scheduling management – To ensure that all required jobs run according to schedule on all platforms for all applications, remember not everything runs through a user interface.
- Actively monitoring applications, triggering alerts, and generating automated issue requests and then informing key operations people of an issue.
- The last thing you want is the CEO calling you at home because the system is down. You want to know first, not last.
- System Logging and Tracking – Apps always need to constantly log and track their activity. So, in the event an issue happens it is easy to review the log and help pinpoint an issue. It is like leaving bread crumbs.
- Database maintenance – Applications and users maintain the database from a database integrity viewpoint. In other words, they know their data and its business meaning, whereas operations maintains it from an efficiency and processing viewpoint (cleaning up deleted records, re-indexing, creating new indexes and views, backing up, etc.)
- Data movement, file transfers, and moving transactional data to a data warehouse for example.
So whether the operations work is customer-facing or in the background, they are both supporting the end user, customer, or client to get their work done in the most effective and efficient way possible.
Tickets, Tickets and More Tickets
Operations demand will come in the form of a phone call, email, a filled out a form, and more likely, a ticket. No matter what the original source was, it must always be mapped into a ticket in my opinion. You need a way to collect, organize, track, prioritize, and report on your demand requests. Either the ticket is created by the person having the issue, or the help center, application support team, or other entity will open a ticket for them. Trust me, this makes life so much easier. You may think, “Ah, what a pain… I need to open a ticket or add to a ticket.” But using a ticketing process is an essentialtool for all operations work. The operations world can be crazy busy. If you don’t log and track your tickets, you can’t measure, and if you don’t measure you can’t improve. So, go find a tool and use it. I will talk a bit about tools later in this article. In summary, all demand is mapped to a ticket.
What’s In a Ticket?
A ticket “starts life” as a representation of an instance of potential work to perform, a demand request. For each ticket, you must capture key attributes that will help you make good decisions about what to do with the ticket. Below is an example of a subset of attributes collected about a ticket:
This is a short list. Add whatever additional attributes you need to enable better decision making based on the system you are using. Sometimes, the term ticket is also called an issue or a requirement, or a feature or other term. Call it anything you want as long as you understand it is a unit of potential work in your demand queue.
Timeline of Ticket Events
Tickets have a lifecycle. This is a typical ticket workflow process. Most tools enable you to design your workflow, events, and triggers, so you can customize exactly to meet your needs. Here is a sample workflow process to get you started.
A typical ticket workflow may follow these steps:
- Approval – Your backlog ticket is triaged, reviewed, and based on available resources approved for working.
- Assigned – Based on your available resources and skills, the resources are assigned. This can be one person, multiple people, full or part time, consultants, contractors, or a mix of everything.
- Work in Progress – The ticket is being worked by the assigned resources. Since a ticket may be in this state for a while, the ticket needs to be updated with status so others can see progress or issues easily.
- Ready for QA – The ticket work is complete and ready for QA (quality assurance testing). Though the application developers perform testing as they progress, my use of the term QA refers to testing in the customer environment, so it can behave as close to the real production environment as possible. Therefore, the new code or application has been deployed in a test environment with the necessary data, user guidance, or other environmental elements required to simulate the production environment.
- Customer Approval – If the customer signs off, the ticket will move into the Schedule for Production step. Otherwise, we circle back via the feedback loop.
- Feedback Loop – Customer feedback would be captured with the ticket and it is then re-routed to the development team for remediation. Steps four, five, and six may be repeated.
- Schedule for production – All looks good and the new release can be scheduled for production. The release is now the responsibility of DevOps. In fact, we could modify the workflow above to include DevOps. Ticket workflow systems are very flexible.
- Ticket closure – This is an important step, though it sounds easy. Tickets should only be closed by the ticket initiator. If the help center opens the ticket, they are merely the surrogate and you still need the ticket initiator to say “perfect, let’s close the ticket.” Add any notes, lessons learned, or other artifacts to the ticket in case this issue comes back and this data may be used to help others on future tickets.
A ticketing system or platform is critical. Yes, you could use Excel or Google Sheets if you like to get started with at least something quickly, but a better approach would be a cloud-based, workflow oriented, issue or ticketing system. Here are 18 products on the market today that may help you out. Products are changing all the time, but here is a starter list for you. I am not going to promote any one of them, since like all products, there are pros and cons to everyone. But you absolutely need a tool and the processes to help you manage, track, and deliver a higher quality of output, maximize your resources, and improve morale: since everyone knows exactly what is going on.
- Active Collab
- Agilo For Scrum
- Scrum Mate
Some are free, some are inexpensive, and some a bit pricey. Which should you choose? That depends on your requirements. Here is a guideline:
- Determine a short list of requirements.
- Don’t hesitate, just pick one, move fast.
- Cloud-based systems are cheap.
- Use off-the-shelf settings or templates.
- Don’t customize too much, but configure.
- Train the team.
- Do a quick pilot and making mistakes is fine.
- Either try another tool or start using the tool in a pilot phase.
- Improve and “tweak” as you go.
- Transition to production.
The Bottom Line
As you can see, I am all in for a ticketing workflow system to manage your operations demand and work management. Within many of those tools you can set up your workflow, Kanban boards, sprints, and other work management schemes to best get your work done. Even if you are a team of one or a much larger team, you must collect, organize, track, prioritize, and report on your work requests. The value of collecting your work management data is priceless. It will help you request additional resources, know exactly what the ticket status is at any time, support lessons-learned discussions, provide visibility into everything in your department or team, and countless other benefits. All of this will better enable a quality operations service for your customers.
In my next blog article of this series, I will be tackling “Doing Work Right – Part 2: Projects.” In that blog, will be looking at work management approaches and practices for running projects.
Want to Learn More?
As I mentioned at the beginning of the article, this is a follow-on article to “Why You Need Demand Management.”
If you want to learn more about demand and work management, please check out one of my Pluralsight courses: Demand and Work Management: A Practical Guide by Michael Krasowski. URL: www.pluralsight.com/courses/demand-work-management.
Fairway Technologies Inc.