The Story of an X-Guy

In the beginning, an analyst is assigned to a project and he knows nothing about System X. He asks questions, talks to the user base, the stakeholders, management, infrastructure people, developers and he learns. By the end of the project he knows volumes about System X. The following year there’s a new initiative with System X. We, as management have to make a decision: do we assign it to the same analyst because of his level of expertise, or do we assign it to someone new? In general, we like to assign projects to the same people because it decreases cost in terms of training and requirement gathering time. So we give the project to the same analyst and the project is done quickly. Requirements gathering sessions go much faster this time, because the analyst knows what questions to ask and there are some questions he doesn’t feel the need to ask. He leads training sessions again and at this point he’s known around the firm as the System X-Guy. He functions as a help desk. He writes requirements for new initiatives in the system with minimal user contact. He has advocacy about the system’s use, why decisions have been made, what needs to be better. He works within a silo.

The X-Guy is pretty easy to spot in your office. He or she is the business analyst who answers questions about business needs without consulting the business. More importantly and dangerously, the analyst will frequently serve as a filter to determine what questions “need” to be asked of the business. Typically organizations claim that they want analysts to elicit requirements. Some organizations don’t work to find a balance between Subject Matter Expertise and Business Analysis, and really want an analyst who will set requirements. For them, the analyst who cranks out requirements is a great resource. The Project Manager says the team needs to have requirements by last week so we can meet an unreasonable go-live date. Pressure! Produce a requirements document now!

But if we have an opportunity to trust in a true discovery process, to let our analysts gather requirements rather than set requirements, we should take it. The benefits of having proper requirements gathering are well documented: a reasoned approach which benefits all, fewer “ah-ha” moments during coding and deployment, a more satisfied group of stakeholders. Though we may as Subject Matter Experts be able to document requirements quickly, we may want to let someone else do the requirements gathering. To put it simply, why pick your own brain when someone else can do it for you?

But I Am Impartial

I found myself setting requirements today in a meeting. We had a discovery session and a stakeholder was asking about moving a delivery time for some data. Rather than indicating that I would follow up outside the meeting, I said that we had talked about that issue on a similar project last year, and that we had made the decision for reason XYZ. She came back with a genuine question, “oh so we don’t need to revisit that?” I immediately realized what I had done. I stopped the discovery process by speaking as an SME rather than collecting answers and doing the analytical work. I immediately reversed course and offered to find those original conversations in e-mail and revisit the decision process. After all, a lot may have changed in a year.

It’s natural to promote a solution based on a worldview: past experience, knowledge of users, knowledge of a system. But if that is not our role or what we want our role to be, we must remain vigilant. A good way we can check ourselves as analysts is to watch for when we answer questions for the business in terms of the To-Be state rather than the As-Is state.

Do we get this report now? Yes. I can answer as an SME without threatening my requirements gathering effort. Do we need this report in the future state? Yes, they get it now. I have acted outside of the rules of requirements gathering. I have used my Expertise about the “As-Is” model to answer a question about “To-Be” for a stakeholder. I am creating a requirement. I have become a stakeholder. We can avoid X-Guy behavior and like a judge, recuse ourselves when our Subject Matter Expertise interferes with our role. We can let someone else pick our brains.

A Noble Experiment

We have a dedicated team of analysts across the country and our project selections are frequently based on our location. Last year we were working on a large initiative across my group. It was a big system change and we needed to rework some processes on upstream systems. As a group we had talked during meetings but also at the water cooler, about trying to do it right this time… not just doing it again. So we decided to try an experiment. Instead of having the analyst who usually worked on that system gather the requirements, I did it from 1500 miles away. The analyst attended meetings simply to answer As-Is questions, and be an SME.

I conducted several meetings remotely with the business users, management, compliance, and the SME, and we were able to determine the requirements for the project. I asked a lot of simple questions. Why do we do this? Is it a system limitation, or convenience? Is the system limitation still an issue? Do the users like the process?

My questions made the process take substantially longer because we engaged a larger group of stakeholders than normal and talked about every facet of the process without writing anything off as “something we just do.” We double checked procedures at an organizational level which meant we had to go to Legal and Compliance. We spoke to users. We diagrammed work flows. Really, we covered all our bases.

In my case, I learned a lot about that particular product offering and the way we processed it. I also got to meet a new group of users I don’t normally work with. But more importantly, we as a group were able to identify opportunities to make positive change. Some of those changes were not directly related to our project, we found other groups’ procedures which could be improved.

I don’t know how the project would have gone without the experiment. I have to assume that another analyst would have been just as thorough. But I also know that my lack of Subject Matter Expertise brought up questions, opportunities, and conversations that wouldn’t have existed if everyone in the room “knew what was going on.” The cost was higher than if one person set requirements. But the benefit was a thorough requirements document and an understanding that we had paved the way for the best process possible.