Skip to main content


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.