Prioritizing Requests

In IT, small projects or problems are addressed quickly. The help desk professionals in IT work exactly like the customer service representatives, handling calls as they come in. But when it comes to medium or large software development projects, work is done in a very different manner. Each request becomes a project. This difference, when not understood by the business stakeholders, will be a huge source of frustration. One of the first tasks in learning the business is to determine if the business stakeholders have ever been involved with a project and what their experience has been.

When a business person requests a change from the IT department, the request is rarely answered or completed immediately. Best practices in IT management dictate that all IT requests are reviewed and prioritized. Often a preliminary estimate is prepared. If the request is large, it may be presented to a governance board for approval. Typically a business case is developed. When the request is approved, it is prioritized against other outstanding requests and is scheduled when resources are available.

This diligent consideration of every request takes time. Requestors may not be adequately informed about how their request is being evaluated. Many business people feel like IT requests disappear into a “black hole.” Business analysis professionals must understand the differences in working styles between their business stakeholders and IT. Learn the IT prioritization rules and practices and be able to explain them to the business stakeholders. Offer to assist the IT prioritization committee with cost justification for important requests. Be the advocate for the business to get requests quickly approved and scheduled. Most IT departments have more requests than they can answer, so properly prioritizing work is critical in providing the highest value to the business. This backlog is one of the reasons why agile approaches to developing software are becoming popular (see Chapter 5). IT recognizes that it has to answer business requests faster.

Ideally, BAs would have work experience in both the business and IT environments. Acting as a bridge between business people and technology people, BAs need to understand how both sides work. If you only have experience in one of these two environments, talk with your manager and consider working as an intern in the other group for six months or so.

Case in Point

Most of my work experience had been in IT departments when I started my first company. My work experience had all been project work. I was suddenly acting in the role of a sales professional. For me, working in an environment where I had to be immediately reactive to customer requests was very difficult. When I initially moved into this role, I did not return phone calls immediately. I prioritized and scheduled them around my other work. After losing several sales due to slow responsiveness, I learned that being responsive and reactionary is a very different mind-set from project work. I don’t think that either situation is better than the other or that workers in one environment work harder than the other; they are just different.

BAs must be aware of these differences and prepared to discuss them with stakeholders. IT people get frustrated when the users are not available for testing. Users get frustrated waiting for software fixes that they reported months ago. A BA’s job is to understand the source of these frustrations and communicate the reasons for the different working styles. There are very good reasons why a company has different departments and different working rules for each. Truly understanding these differences helps BAs to more effectively serve all stakeholders.