EA 872 Week 10 How to measure the gap

Hello! Thanks for reading! If you have been here, before welcome back!
This week we had readings dealing with Gap Analysis and Road Maps among other items.  I started discussing some aspects of Road Maps in my week 8 posting here

http://joec3s.blogspot.com/2016/03/ea-872-week-8-route-planning.html

I also wrote some details about the project complexity assessment technique here in week 6

http://joec3s.blogspot.com/2016/02/ea-872-week-6-low-hanging-fruit.html

For this week, I am going to continue along with on an item I touched on at the end of the post, project complexity and gap analysis. Project complexity analysis is an assessment technique that can be used during a gap analysis effort. When moving towards a future state architecture, it is important to understand the impact of any given project or process. Complexity Assessment is the process of determining the scope and initial timeline of any project or sub-project associated with future state effort. Each effort is assessed based on its Requirements Complexity and Environment Complexity.  Each complexity dimension uses multiple evaluation criteria to accomplish a sensitivity-based assessment.

Requirements Complexity is a measure of how complicated it is for a  delivery team to provide the solution to the business users.

Environment Complexity is the measure of how well the current state environment supports the expected needs of the solution.

The goal is to map an effort, based on complexity,  into a project type (1,2 or3). You can get more detail on the "Types" in the week six link noted above. To pull this all together and better understand this process I have attempted to break out the complexity elements as I might approach them during an assessment effort. Assume that this is a Business Intelligence reporting or data analytics effort.


Requirements Complexity
Requirements complexity as stated  is a measure of how complicated it is for a solution delivery team to provide the reporting solution to the business users.  The requirements complexity criteria are listed below.

Graphical User Interface
Customization of ‘out of the box’ functionality:

• High – more than 20%
• Medium – under 20%, but greater than 10%
• Low – 10% or less

Analytics
How much analytic functionality is required in this solution?

• High – requires advanced analytics, newly defined business process.
• Medium – calls for advanced analytics, existing business process.
• Low – a take it or leave it.

Security 
What is the expected security level required for this solution?

• High – new security model required. 
• Medium – role and data level security; could have regulatory issues.
• Low – role-based, no expected issues.

Reuse Effort 
What is the expected reduction in effort due to the use of a reusable assets?

• High – less than 50%
• Medium – over 50%, but less than 80%
• Low – 80% or more

Expected Deployment 
How many users are expected to be using the deployed solution?

• High – over 500 
• Medium – less than 500, but more than 50
• Low – 50 or less

Environment Complexity
Environment Complexity as stated is the measure of how well the current deployment environment supports the expected needs of the solution. The environment complexity criteria are listed below.

Architecture Development
What is the expected need for new architecture components for deploying this solution?

• High – new architecture required (source data – staging – repository – reporting) 
• Medium – new repositories and/or data mart required
• Low – existing deployment environment sufficient

Software & Hardware
What is the match with the currently deployed software and hardware within the development and deployment environments?

• High – None, new software and/or hardware platforms required
• Medium – some new hardware or software required, but not currently used in other deployed solutions
• Low – current environment meets needs

Data Sources
How many new data sources are needed?

• High – more than three new data sources required
• Medium – 1 to 2 new data sources required, but sources not qualified and/or new transformations required against current data sources
• Low – no more than two new data sources, but from qualified sources

Reports 
What is the adequacy of the current reporting capabilities?

• High – new business reporting required
• Medium – expanded reporting required, needs business validation
• Low – current reports, interactive features only

Business Rules Development 
Are there existing business rules that support the reporting requirements of this solution?

• High – new processes being developed, business rules dependent on completion
• Medium – new business rules required for current or new reporting
• Low – existing business rules used in current reporting

As I noted above getting to that project type is the ultimate goal of this effort. This classification can then be associated with timelines and cost thus adding tremendous value to the gap analysis efforts.
This information, in turn, helps ensure effective expectation management from the very early stages of project inception.

If you want to see something similar in action look at this link for the Canadian government. 

http://www.tbs-sct.gc.ca/hgw-cgf/oversight-surveillance/itpm-itgp/pm-gp/doc/pcra-ecrp-eng.asp

This approach is quantitative with the way it scores out and the added depth it takes. 

Thanks again for reading and as I stated last week I hope this starts to tie together these past posts into a more useful framework.