Forums for the Business Analyst

  Modern Analyst Forums  Business and Sy...  Business Proces...  proof that Enterprise Analysis workds
Previous Previous
Next Next
New Post 5/1/2013 6:08 AM
User is offline Tony Markos
493 posts
5th Level Poster

Re: proof that Enterprise Analysis workds 



Analysis of an Enterprise  is a complex endevor.   To accomplish such requires a very straight forward, concrete approach.    Key Principle:  A BA can not address complex problems with a complex or hazy methodology. 

To expand:  What is a business case?  The business case answers questions like:

  • Why are we doing this project?
  • What is the project about?
  • What is our solution to the business problem?
  • How does this solution address the key business issues?
  • How much will it cost?
  • How long will it take?
  • Will we suffer a productivity loss during the transition?
  • How will the business benefit?
  • What is the return on investment and pay back period?
  • What are the risks of doing the project?
  • What are the risks of not doing the project?
  • How will we measure success?
  • What alternatives do we have?

So what?  How does one, simply and straightforwardly provide concrete answers to these questions?  My answer:  In the main, create integrated Data Flow Diagrams.  They very uniquely will guide you to answers to most of the above questions.    DFD's at the same time also integrate business requirements and stakeholder requirements. 

One may not agree with my approach, but, unless, one can verbalize a simple, straightforward, concrete approach to answering the questions, he/she will probably have significant issues.

New Post 5/1/2013 12:52 PM
User is offline Sandy
74 posts
8th Level Poster

Re: proof that Enterprise Analysis workds 

Hi Mike,

Are you looking for a Business Case that justifies why you should be developing business cases?  :)  I don't have any stats handy for you that measure Enterprise Analysis efficacy as such (perhaps because the outcome depends on how well an organization actually does it), but can give you some ways you might measure the need for it within your organization.  Analyses of project success rates consistently show low rates of fully successful projects - such as the Standish report findings that only about 35% of projects are successful, while about 20% fail completely and about 45% are 'challenged' (don't fail, but don't fully deliver either).  While projects fail for a variety of reasons, Enterprise Analysis is targeted as some of the common failure points.

Symptoms of the need for Enterprise Analysis include:

  • Do your projects typically encounter issues with stakeholder engagement? (Stakeholders do not buy-in, or don't have time to meet conflicting priorities, demands from concurrent projects, etc.)
  • What is the typical lifespan of application systems?  Are applications typically retired because they're no longer needed, or are they more often replaced or re-engineered because they just don't meet "evolving" business needs?  It's rare for businesses to radically change their business model - most often, if a system doesn't meet business needs it's because those needs weren't fully understood or addressed to begin with.
  • Do people in your organization complain that their application systems aren't 'flexible' enough to adapt to business growth and change?  See above....
  • How much time / effort / money is invested in enhancements to new application systems within the first 2 years after implementation (not requirements that were postponed, but additions or changes not identified until after the system went into production.)
  • How are projects currently initiated in your organization?  Are the business needs documented at the start of new projects?   If so and if you have access to previous project documents, then it might be interesting to read through them and see how often the same / similar needs keep cropping up - because they were not truly understood or not not fully addressed by those projects.

These are the types of business problems that Enterprise Analysis is intended to solve.  Its justification is based on reducing the occurrence and organizational cost associated with these problems.  It's intended to make sure the business needs are fully understood and priotizied, that stakeholders are committed (at all levels of management), that projects are adequately resourced, that the right solution is found / delivered to solve the defined problem(s), etc. 

Hope this helps.


Previous Previous
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  proof that Enterprise Analysis workds

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC