Author: Srinivas Laxman

Perspectives

Written by Srinivas Laxman on April 9, 2020. Posted in Articles.

As a Business/Systems analyst or Solutions Architects we are Technical Leaders for the systems we represent to the business.

We have incredible influence on wide range of stakeholders during the analysis, architecture and the end to end solution delivered. We hand hold the business as they try to unravel the incredible complexity IT brings to the table to help deliver the business value. And at the same time we can strive for simpler implementations and identify red flags that could help our development and operations stakeholders.

Here are some of the perspectives that an analyst must be aware of and can use it to further enhance his influence on the project.

Business Perspectives

I have been in several meetings with Business stakeholders where the business language they use for certain features or scenarios are completely different as used by IT stakeholders. These can cause back and forth discussions and confusions during solution reviews. Smart analysts understand this and acknowledge these discrepancies will always exist due to diversity of stakeholders. They will bring these up at the right time and align both teams – there by ensuring both teams are aware and can work around it.

Another of concerns of business stakeholders is the use of excessive technical jargons in the functional requirements which delay the sign off and add complexity. Thus, business greatly appreciates analysts who use the simplest language as possible and whenever required provide clarity on any jargons if used. That way they are not alienated and fully aware of the technical solution they are signing off. You may have seen the internal memo sent by Elon Musk banning all technical jargons at Tesla.

Finally, business always looks for an honest voice, one who brings to the discussion table issues or gaps or critical roadblocks at the right time instead of pushing it under the rug to be discovered later. Such analysts are greatly valued for their strong voice and to help business identify upfront mitigation plans and not at the tail end of the project.

IT Perspectives

Management of scope is one of the most important expectation from the IT teams is that analyst should spend enough effort on. Highly respected analysts do this regularly and continuously control the scope to push back when required and at other times steering them through change management process. There by shielding the development team members of the constant influx of changes.

Development/operations teams are always wary of the massive amounts of code that will be written and pushed to production as part of new projects. From their perspectives one of the main expectations is that the implementation should be simple enough to develop and maintain. Analysts can play huge role here by identifying red flags when things are becoming complex, making their stand and nudging business teams to think of reducing complexities to achieve their business goals. Finally, nobody wants to end up with a system that is too hard to understand and nightmare to maintain.

During implementation phase IT Development/Operations teams usually come up with highly relevant set of questions and important scenarios that need to be clarified with business. These are invaluable insights that when the analysts should make sure to track and close can hugely influence the quality of deliverable. I have seen projects where these when ignored usually end up as UAT issues, which could have been easily discussed and closed during the requirement/development phase.

Analyst Perspective

Analysts have to regularly ask what the technically right thing is to do in situations which require critical decisions. For example, there could be a quick fix that could solve business requirement, however highlighting that business rather wait and have long term fix which will ensure better technical solution and also save costs will be better appreciated by both sides of the stakeholders.

The analyst must continuously think several steps ahead and keep looking at big picture. Such analysts also push for proof of concepts and early integrations to happen since they are usually the gaps which are identified late in the project deployment stage. They may also influence in the receivables and deliverables of the project with the integration partners to ensure the configurations and touchpoints are well tested prior the launch.

Thus, such analysts have clear strong vision of the solution they are creating and in addition to catering to business and IT stakeholders also chart the right path for the project that is in line with the overall enterprise architecture.

4 Key Learnings as a System Analyst

Written by Srinivas Laxman on October 3, 2017. Posted in Articles. 1 Comment on 4 Key Learnings as a System Analyst

Five years back, I transitioned from Software Development Lead to System Analyst position at large North American Telecom account.

At the onset, my focus was to mainly on capturing functional requirements to help deliver projects on time without any design gaps. This invariably meant my attention was focused on documents, checklists, and procedures. Interestingly, it was only later after collaborating with some excellent peer analysts and observing their behavior did the finer aspects of the role became clear to me.

Here are some of my highlights and personal learnings about the world of Analysis.

Beyond Liaison role

The analyst role is often mistaken to be purely liaison role that acts as a link to assist communication or cooperation between groups of people. This may result in analysts focusing on packaging set of Requirements and delivering to IT and vice versa. An analogy to real world could be mail delivery person delivering package from source to destination. Often with faint idea what’s inside the package. There is little to be motivated about such role and it ends up limiting breadth & depth of influence of an analyst.

On the other hand, some of extraordinary peer analysts I have worked with instead, routinely go beyond liaison role. They are not shy to open the “package”, try to understand contents, ask some questions and gain deeper understanding. They take effort to translate contents to audience-appropriate language and then deliver to recipients. Other times they re-arrange the set of ideas in way that makes the subject clearer. Thereby such analysts add value to chain.

By stepping outside the role of liaison analysts can bring lot of value to project and discover the real essence of the profile.

Power of questions

This is an area where I consistently struggled to adapt during my journey into analysis world from development. Each time I heard of requirement, my mind would immediately have jumped ahead to try to solution. I was more focused on solutioning part and was missing critical piece of stage in the analysis and that is the questioning part.

Interestingly some of peer analysts were doing it bit differently and it was interesting to observe and learn from them. They took the time to ask probing questions to understand the needs better or simply to ask thoughtful relevant questions. Questions like “Can you elaborate this further with a business use case?” or simply to understand “What is the business benefit in implementing this?” A lot of times this not only clarified ask for technology teams but also brought to discussion some finer aspects of requirements.

Author Andrew Sobel elaborates this concept clearly in book Power Questions – “Good questions challenge your thinking. They reframe and redefine the problem. They throw cold water on our most dearly held assumptions, and force us out of our traditional thinking.”

The analyst need not have all answers, yet the art of asking probing questions is the one to be learned.

Stakeholder Relationships

The analyst must have an innate ability to work across large group of stakeholders and effectively lead and manage the relationships. These range from several of the business stakeholders from marketing, legal, accounting, customer experience and over to the technology world comprising of development teams, architects and delivery managers.

Age old attributes in relationship building like trust, straightforwardness and honesty never go out of fashion. The peer analysts in my team who were always pursued out for most high visibility projects were highly trusted individuals and their personal characteristics flowed into their work.

System analysts also have perfect opportunity to recognize the behind the scenes technology team and share the due credits with the team. Thus at the outset the analysis role may not appear to be managerial, however some of thriving analysts on our team were the ones who exhibited leadership and team building skills.

Adjusting the Lens

Finally, the analysts that were highly successful were the ones who could balance the level of detail. The critical ability of system analyst continues to be able to deep dive into functional area and come up with scenarios, clarifications, user stories that capture and cover the business needs. Yet there are several instances when teams are involved in details and lose sight of the big picture.

That is where some of excellent analysts stand out in their ability to balance their attention and level of detail. During discussions with developers, such analysts delve deep into the topic and come up with various scenarios that help supplement the analysis. And on the other hand, while discussing with business and leadership, they have ability to summarize it appropriately to communicate the gist.

The skill of analyst to be able to fine tune the lens and clarify the picture to the audience is always highly appreciated.

Thus to conclude, the role of System Analysis lies at the very cusp of dynamic Business needs and ever evolving Technology layer. It’s exciting to realize that the boundaries and influence of the Analyst are limitless on the project. I wish you luck on your journey and learnings on this path!