Focus More on People Process, Less on IT Tools

Focus More on People Process, Less on IT Tools

There are many Information Technology (IT) and IT Service Management (ITSM) tools, from custom developed products to commercial-off-the-shelf (COTS) products to professional cloud offerings, out there in the market; per my observation, one thing is common – tools are as good as the people-process using them.

People

Although, it is a universal concept, nonetheless, it is one of the most common causes of the mistakes in the IT world that teams make while identifying the key stakeholders. On one end of the spectrum, they include the entirely wrong set of groups and organizations as owners (or influencers), whereas, on the other end, there are virtually no owners.

In the former case, usually, the folks are preaching on a problem with some buzz words they may have heard in a town hall or a seminar without a full grasp of the situation.

Related: Dare to Ask, Why?

Whereas, in the latter case, usually a team in an enthusiastic and siloed manner cook up their solution(s) on an assumption of a perceived problem in the company.

In between the two, there is a range of people problems that can exist in a given situation at any big corporation.

Define RACI

One can apply the project management principles to address the people problem. It is an essential part of the Project Manager’s (PM) job to identify the appropriate stakeholders for every project. After determining the stakeholders, focus on defining the RACI (responsible, accountable, consulted and informed) matrix. Know who has the authority to say “do this” and “don’t do this.” Know who is responsible for providing solutions, and who isn’t. For example, the PM should not answer the technical questions, and the development team should not decide what functions are critical to the business (or process) owner.

Listen

Once identified, listen to the customers, users, stakeholders, or influencers of the product (or project, system, or what have you). Do not shove the solution down their throat with the hammer of “industry best practice” or “that is how it worked at the previous company (or client).” No, the customer is not an idiot. They are humans facing a unique set of challenges at different companies (or in different environments). Treat them with the respect they deserve. Arrogance, miscommunication, or lack of communication among people is toxic for everyone in the long run – avoid it.

Process

My definition of the process is how the above-identified people interact with one another to achieve a predefined function. In other words, a phenomenon where a person (or a group) is entering some inputs, people acting on the information received, and providing the result(s) of the action(s) taken. One may repeat this model depending on the situation for concluding end objective of the process.

Again, it is the people (owners, customers, etc.) who define the process. The notion that a “process” is “universal” is not helpful; it might be universal in concept, but applications of the same could be different in varied environments.

Discuss

The beauty of whiteboard session is that not only it empowers the customers in rethinking and articulating their business case with clarity, but also it helps everyone gain each other’s trust.

Some may argue that there are industry best practice solutions and frameworks available, no need to waste time on the discussions. In my view, the best practice is what works in the given environment to achieve a business function, with minimal effort, cost, and overhead. Of course, there are some excellent frameworks out there to guide folks. But one must keep in mind that the “frameworks” are for guiding and reminding of series of steps, not a standard or a code that one must adhere to by hook-or-crook. It is where the People make their most impact on the Process. One can review the framework and may say, “We need to tailor this, XYZ does not apply to us; QPR  is just nice to have not as important as other items, etc.”

Respect the Decision

At times, following the approach mentioned above may bring the deep-rooted strong opinions to the surface. Some may call it a passion. It is good to voice opinions, especially, when one disagrees with something. However, considering the RACI aspects, one should keep those opinions at a level of mutual respect. Give the benefit of the doubt to the person in authority who may have better visibility into the big picture. However, one can use the MVP approach as a mode to validate the assertion (or a point of disagreement).

Related: When You Have to Carry Out a Decision You Disagree With

IT Tools

MVP (Minimum Viable Product)

Have you noticed, thus far, there is no mention of the tool? For the most part, the business case is agnostic to the choice of a product.

One of the most critical and limited resources is time. Folks want things done, i.e., there is an anticipation of faster time to market for the product launch. The idea is to come up with a solution that meets the bare minimum set requirements for the business case.

Learn with that MVP, test hypothesis, fail fast and iterate to improve. Most of the times, the folks do not know what they want, or how they want a system to look like, or process to work entirely in the beginning. The MVP approach includes prototyping, charting, surveying, power-users sessions, to help refine the product that People of the organization will use as part of their day-to-day job.

But the XYZ Tool Has All That Out of the Box (No It Does Not)

A salesperson (or an advocate) of a tool (or a product) would say, “Sure, it all makes sense. But we have gathered input from industry leaders. And hundreds of companies are using the XYZ tool out-of-the-box.”

If it had been true, the professional service providers would have closed their consulting and advisory businesses. Those “big four” organizations would not be thriving in the industry despite the so-called tools that have everything out of the box!

Of course, some tools do a better job than others. But these tools cannot dictate the people behavior; instead, these tools require tailoring per the demand of the people process identified in a given environment.

Granted, in many cases, the people can be persuaded to follow what the tool is offering. At times, doing so saves time and money. However, the chances of success would be higher if folks would follow the approach mentioned above.  Pay attention to the people and their processes more than the tool.

After all, the people define the processes, and tools are there to serve the people, not the other way round.

Comments are closed.