Having a standard process around the business is nice. However, having it documented is nicer as it helps the business reduce downtime when transferring roles or skill from one person to another, when executing projects, as well as transparency for process understanding and improvements around the business.
Process flow
Catch up with the business requirement (BR) solicitor
BR documentation by the solicitor
Initial BR documentation by the data analyst
Catch up with BR solicitor/stakeholders to manage expectations
Updating BR documentation by the data analyst
Project implementation
Final BR documentation by the data analyst
Catch up with the BR solicitor
Get an overview of the value to be created
Get overview of areas of the business that will be impacted
BR documentation by solicitor
Having a worded request written down could immensely enhance understanding and remove possible grey areas. The documentation should contain:
The background of the request
How the previous process was carried out?
Who does what?
Documents for previous or similar processes
Data sources
Data security
Key link to the reference documents on the previous process
A clearly detailed acceptance criteria for the solution to be created
Initial BR documentation by data analyst
Aggregating knowledge gathered from the catch-up and BR documentation by the solicitor to get an overview of the value created by the previous process and the potential value the new process could create. Meeting with stakeholders around the BR to get a more detailed understanding of the process. Create a new documentation that will be more detailed to the execution of the project. The documentation should contain:
The background of the request
How the previous process was carried out?
Who does what?
Documents for previous or similar processes
Data sources
Data security
Key link to the reference documents on the previous process
A clearly detailed acceptance criteria for the solution to be created
Create a ticket on a project tracking tool (e.g. Jira or Asana)
Catch-up with BR solicitor as well as analyst to manage expectations
Meet with the BR solicitor to discuss based on your investigations, what can be achieved and what cannot at the point in time. This could be a continuous conversation
Updating BR documentation by data analyst
Are there new data requirements?
Are there new acceptance criteria?
Are there new processes to document?
Project implementation
The fit for purpose source of truth dataset used
Orchestration job implemented if any
Transformation job implemented if any
Cards created if any
Dashboard created if any
Final BR documentation by data analyst
Update the BR document. The documentation could contain:
Background
Previous process
Key links: Project tracking tool (e.g. Jira or Asana) | Previous process related documents | New process related documents | Data governance | Background reference
Data requirements containing the features and business logic required to achieve the BR
Key observations
Reconciliation/Change management
Acceptance criteria
Activity notes (if required)
Data quality observations
Is the data entered accurately, are there missing values, how frequently is the data updated?
Does the business logic correlate with the logic used for the features
Catch up with stakeholders to discuss observations
Data security
How was the data secured? Who had access to the data? Are the people having access to the data meant to have access to the data?
Can a similar or better security be replicated using a new process
Reconciliation/Change Management
Is the values from the newly built report equal to the previously built report
Is the values from the newly built report different from the previously built report due to data quality issues
Are the definitions of features from the newly built report what was intended by the business
Catch-up with stakeholders to discuss usability and impact of new process for the BI report
Document new process
Document the new process for generating the report using the BI tool
Following a framework when executing a data project could help reduce downtime, plan ahead, and have an established process in the business others could follow.
Framework
Investigations
Catch up with the business requirement (BR) solicitor
BR documentation by the solicitor
Background
Previous process
Key links to reference documents
Acceptance criteria
Understand previous process and value to be created
Check data sources and documents for previous or similar processes
Data quality observations
Data security
Solutions Implementation
Create data analyst project documentation
Identify sources for new process
Catch up with BR sponsor/solicitor to manage expectations
Create new process
Reconciliation/Change management
Hypothesis around issues or success derived from new process
Extra insights generated from new process
Confirming or discarding hypothesis with solicitor or stakeholders
Document new process
Data governance
Catch up with the BR sponsor/solicitor
Get an overview of the value to be created
Get overview of areas of the business that will be impacted
BR documentation by solicitor
Having a worded request written down could immensely enhance understanding and remove possible grey areas. The documentation should contain:
The background of the request
How the previous process was carried out? Who does what?
Link to the reference documents on the previous process
A clearly detailed acceptance criteria for the solution to be created
Understand previous process and value to be created
Aggregating knowledge gathered from the catch-up and BR documentation by the solicitor to get an overview of the value created by the previous process and the potential value the new process could create
Meeting with stakeholders around the BR to get a more detailed understanding of the process
Check data sources and documents for previous or similar processes
What system or systems was used in capturing the data used in the previous process
Where is the single or multiple source of truth data for the previous process
Data quality observations
Is the data entered accurately, are there missing values, how frequently is the data updated?
Does the business logic correlate with the logic used for the features
Catch up with stakeholders to discuss observations
Data security
How was the data secured? Who had access to the data? Are the people having access to the data meant to have access to the data?
Can a similar or better security be replicated using a new process
Create data analyst project documentation
Create a new documentation that will be more detailed to the execution of the project. Use the documentation from the BR solicitor as a starting point. The documentation could contain:
Background
Previous process
Key links: Project tracking tool (e.g. Jira or Asana) | Previous process related documents | New process related documents | Data governance | Background reference
Data requirements containing the features and business logic required to achieve the BR
Key observations
Reconciliation/Change management
Acceptance criteria
Activity notes (if required)
Create a ticket on a project tracking tool (e.g. Jira or Asana)
Identify sources for new process
Are the sources of data only from systems, or just manual, or system + manual
Can a direct connection be made from the system to the BI Tool so the data can be ingested directly from the system
Can a power app be made for manually entered data so the data can be ingested from the power app
Catch up with BR solicitor to manage expectations
Meet with the BR solicitor to discuss based on your investigations, what can be achieved and what cannot at the point in time. This could be a continuous conversation.
Create new process
Start building the new process using the available data analytics tool that can be better used for the process
Reconciliation/Change Management
Is the values from the newly built report equal to the previously built report
Is the values from the newly built report different from the previously built report due to data quality issues
Are the definitions of features from the newly built report what was intended by the business
Catch-up with stakeholders to discuss usability and impact of new process for the BI report
Document new process
Document the new process for generating the report using the BI tool
Acceptance criteria
Newly built report on BI tool generated same or better report than spreadsheet
Data governace
Define similar or new data governance measures that have been put in place
Codes
Document codes similar to that used on the spreadsheet report that were use on the BI tool
Document new codes for new insights where applicable
Just like every other area of data analytics, migrating a report from a legacy system or spreadsheet to a BI tool can only be done right when you ask the right questions.
Framework
Investigation
Legacy systems
Available ETL tool
Data warehouse
Data governance
Solutions Implementation
Solutions enquiry
Extra Insights that can be generated
Documentation
Change Management
Acceptance criteria
Codes
Legacy systems
List out all the legacy systems used by the business
Available ETL tool
Is the ETL tool able to connect to all the key systems used by the business
Data governance
How was the data secured around the spreadsheet
Can a similar or better security be replicated using the BI tool
Solutions enquiry
Are the sources of data only from systems, or just manual, or system + manual
Can a direct connection be made from the system to the BI Tool so the data can be ingested directly from the system
Can a power app be made for manually entered data so the data can be ingested from the power app
Extra insights that can be generated
Is the BI tool able to get more features from the data source that could be useful for more insights
Are there new values that can be created if the BI tool gets the data in real-time
Are there new logics that were needed by this business area that can be built using the BI tool
Documentation
Document the new process for generating the report using the BI tool
Change Management
Is the values from the newly built report equal to the previously built report
Is the values from the newly built report different from the previously built report due to data quality issues
Are the definitions of features from the newly built report what was intended by the business
Catch-up with stakeholders to discuss usability and impact of new process for the BI report
Acceptance criteria
Newly built report on BI tool generated same or better report than spreadsheet
Codes
Document codes similar to that used on the spreadsheet report that were use on the BI tool
Document new codes for new insights where applicable
Just like every other area of data analytics, migrating a report from a spreadsheet to a BI tool can only be done right when you ask the right questions.
Framework
Investigation
Current value of the report
Data quality observations
Data security
Solutions Implementation
Solutions enquiry
Extra Insights that can be generated
Documentation
Change Management
Acceptance criteria
Codes
Current value of the report
Identify what value the current report creates
Identify the system or manual sources of the data
Identify who uses the spreadsheet report and what they use it for
Data quality observations
Is the data entered accurately, are there missing values, how frequently is the data updated
Does the business logic correlate with the logic used for the features
Catch-up with stakeholders to discuss observations
Data security
How was the data secured around the spreadsheet
Can a similar or better security be replicated using the BI tool
Solutions enquiry
Are the sources of data only from systems, or just manual, or system + manual
Can a direct connection be made from the system to the BI Tool so the data can be ingested directly from the system
Can a power app be made for manually entered data so the data can be ingested from the power app
Extra insights that can be generated
Is the BI tool able to get more features from the data source that could be useful for more insights
Are there new values that can be created if the BI tool gets the data in real-time
Are there new logics that were needed by this business area that can be built using the BI tool
Documentation
Document the new process for generating the report using the BI tool
Change Management
Is the values from the newly built report equal to the previously built report
Is the values from the newly built report different from the previously built report due to data quality issues
Are the definitions of features from the newly built report what was intended by the business
Catch-up with stakeholders to discuss usability and impact of new process for the BI report
Acceptance criteria
Newly built report on BI tool generated same or better report than spreadsheet
Codes
Document codes similar to that used on the spreadsheet report that were use on the BI tool
Document new codes for new insights where applicable