window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-YFZ1F7T6M6'); window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-YFZ1F7T6M6');
DataHub Consulting, Experts in Analytics, Business Intelligence, and Compliance 1200 627

Written by

Date

1 January 2024

Category

I was recently asked the question from a client who is thinking of embarking on a technical development project in Q1/Q2 of 2024, “What makes a successful development project?”. This got me thinking of projects that we have implemented at Datahub Consulting, but also the projects that I’ve personally worked on when I worked for Microsoft gold partners as a solutions architect.

From my experience, a successful development project extends beyond the development capabilities. There needs to be commitment, resources, and engagement from both the development team and the business. It requires a knowledgeable and capable development team. This could be an internal team or using a consultancy like Datahub. Secondly, there needs to be a buy-in from the business from the top down. Having a new data warehouse, migrating from an on-premise to cloud architecture, or a re-development of the organisation’s core reports are big investments for any organisation. When I say big investment, this includes financial investment but also investment from of time from internal resources. An internal team of stakeholders will need to spend time on the project.

Let’s have a look at some of the key points of implementing a successful development project.

Stakeholder Engagement

I mentioned above that for a successful project to happen, in my view there needs to be commitment and engagement from the business. This involves a team of stakeholders being involved from the planning through to final sign-off. There also needs to be a product owner that has the ability to approve changes and sign off deliverables. We will discuss the importance of the product owner further down in the article.

Planning

Planning is key with any successful development project. The development team will need to have an understanding of the requirements, the data to included, who will use the reports, and finally the quality of the data they will be working with.

This process is often completed in a discovery session, or sessions.

Documented Solution

With any successful development project there needs to be documentation. After the planning and discovery then a technical and non-technical solution document will be created with the architectural approach. This will then be the backbone for the project development.

Once that the development of the project is complete or near completion then a data dictionary for example will be created for the business. If you use a consultancy then the technical and business information will be in their heads and needs to be documented.

Trust in the Data

A common failing that I’ve seen with projects is that the business doesn’t have trust in the data. When this happens, the project will fail as users will be reluctant to use the new system. I’ve seen it where users have kept to their own excel reporting because they have stated that there is no trust in the other system. Datahub have been used on a couple of projects where an internal team have created a reporting solution that some of the business does not trust. We were asked to investigate and recommend a solution.

When I speak with clients and understand their frustrations, challenges, and mindset, there can be trust issues with the data. This could be for a number of reasons. Here are some of the common ones that we have experienced with clients.

Data quality

To many projects fail because time is not allocated to looking at the data quality and resolve any issues found.

We worked with a client where their transactional data was managed by a third party which meant that they had restricted control over data quality. When implementing a Power BI project, we were told to use the data “as is”. They thought that data quality was not important and wanted to save money and time by not looking at their data. This had a negative impact over time. We did some basic data validation checks for our own piece of mind and found:

  • Non date values in a date column
  • Excessive number of nulls and blanks
  • Text in number columns

We implemented one model and one power bi report using the “as is” data to demonstrate how the inconsistencies and data quality would affect the reporting. The client understood and followed our recommendation of understanding and addressing data quality issues.

More than one version of the data

This is common where each report has its own dataset with calculations embedded in the data. Over time one report could be changed and two similar sales reports give two different answers.

Another example is where different parts of the business have their own data (siloed). Not having centralised data can lead to discrepancies and variances in data. For example, if an organisation has sales teams within different territories. And each territory is responsible for managing their own data, data quality, calculation in the data, and separate reports. Could that data be compared like for like?

With the clients that we have worked with, we have seen it where one territory uses Microsoft Power BI for reports, and another territory used QlikView. In this example they had totally different systems and an issue was identified where one system rounded numbers and the other didn’t. Over a year this amounted to a significant difference in financial data.

Different departments use different business logic.

There are cases where we have seen different business logic for a particular calculation within the business. The operations side of the business could state the logic for a sales-based calculation. But the finance team will look at it from their financial reporting and state that the business logic needs to be different. Which one is correct. We have seen this a number of times with currency conversions where an organisation operates over a number of countries with sales in multiple currencies.

Users having the ability to change business logic.

In my opinion there needs to be controls in place to manage any change with a technical solution. These controls would be access, backups, version control, and an approval process.

I’ve seen instances where users have the ability to make changes to calculations within report data without the means to rollback or have an approval process in place. In this case any changes would not have easily been detected.

This can lead to inaccuracy creeping into a project and not being detected with testing and validation. In the instance that I experienced, there was a SQL based data warehouse, excel reports used “power query for excel”, and a sql script was used by power query to pull the results. Mangers had elevated permissions so that they could make changes to the sql scripts without any additional controls.

This is an example calculated data can be changed leading to inaccurate numbers for the business. There was also no method to monitor any changes. For this reason the business did not have trust in the report data.

One version of the Truth

We started to discuss this above, having one version of the truth that is approved by the business is the way forward. Having one centralised model that is used for multiple reports is the best approach. Getting a consultancy to create this would be advised to create the code for the business logic, optimise the model, validation, and set up the security. Then the business can use self service techniques to create the reports if required.

Having one centralised model means that there is one version of the truth, the numbers are validated, and if chances are required over time, then it’s done in one place and reflected in all reports thereafter.

Approach

Working on development project for 20 years I’ve seen the approach to projects change, for the better. Years ago, all development projects were delivered in a waterfall methodology. Where the large-scale project was delivered over a long period and finally the customer would see the outcome. This could be 6 months of not seeing anything then the project would be deployed and available to the customer.

Today the approach is agile where the large-scale project is broken down onto smaller deliverables, with each deliverable broken down in to sprints. For example, with Datahub we work on two week sprints with our projects.

So, what are the benefits of agile?

  • The business sees the outcomes quicker.
  • Regular show and tells
  • Change requests are implemented easier.
  • Better engagement with stakeholders.
  • Manage workloads through a kanban board.

What is a Kanban board?

There needs to be a method to monitor and control the project items. This is where a kanban board is used. With a kanban board the project management team can focus the development team on the work items that are prioritised. With the Agile sprint planning it will be agreed what work items will be included in the next sprint. These items will then be included in the backlog of the Kanban board. Developers can then select an item to work on from the backlog and will progress the item through to completion. Typically, a kanban board will include backlog, in progress, testing, and completed. But other categories can be added to suit the project.

A Kanban board can be a digital application or as simple as Post-It notes on a board. This then helps the business and project management team to understand progress against the current sprint with a visual representation. This provides a method to maximise development efficiency and workflow.

Accountability & Responsibility

There’s a difference between accountability and responsibility within a project. For a project to have a successful outcome then there needs to be the level of accountability and responsibility.

As part of the project management Datahub Consulting regularly create a RACI matrix for projects to understand who is involved for key aspects of the delivery.

For any given part of the project who has Responsibility, who is Accountable, who will be Consulted, and finally who will be Informed.

RoleDescription
ResponsibleSomeone that is responsible is the person or persons doing the work. They are responsible for completing the task based on the requirements. In majority of the projects this would be the developers.
AccountableSomeone that is accountable is a person or persons that are accountable for the decisions, actions, and outcomes of the project (or part of the project). For example, a particular manager could be accountable for making sure that the project goes live on a particular date. They don’t have to do the work themselves but are accountable for the outcomes.
ConsultedConsulted is a person or persons that is not actively involved in the project but because of their knowledge or experience are valuable to the project success. This is a person that will be asked for their input. For example, if you are creating safety reports for an airport then this could be the person that heads up the health and safety team.  
InformedInformed is a person or persons that is not actively involved in the project but is kept informed on progress. For example, this could be the senior leadership team.
 

Product Owner

With any successful project there is a product owner. So, what is the product owner?

The product owner is part of the business and not part of the development team. They are responsible for prioritising and overseeing the development team’s tasks. Making sure the company derives as much value as possible from the development work. Making sure that the development team meet the objectives and required outcomes of the business.

Technical Considerations

This is not aimed as a technical article so I’m not going into depth on these topics, but any successful project would need to consider:

  • Source Control – A method of keeping a history of changes and the ability to roll back if necessary.
  • CI / CD – Continuous integration and continuous deployment (CI/CD). This is used to create a deployment pipeline process. You can use tools like Azure DevOps to do this to enable teams to work collaboratively on a project.
  • Knowledge and experience – Assess the skills and knowledge if the team to ensure that they have the knowledge & experience to achieve the outcomes. I’ve seen on a number of occasions where internal teams have started a development project and found that additional resource from a consultant is required. The quicker you can identify any additional resource requirements the better it is for the project and the budget. During the planning stage I would recommend assessing resources.

In Summary

For a project to be successful then it needs to meet it’s objective and outcomes. In my opinion taking the above into account will help to achieve this. The business needs to invest in the project for it to be a success. They need to invest time, stakeholder resource, budget, and this needs to be from the leadership team down.

Think about the internal capabilities and the time commitment that an internal team would need. Will it take them from their day-to-day BAU work. This is the benefit of using a consultancy. But in doing so there is budget considerations.

Working With Datahub Consulting

It wouldn’t cost you anything to start a conversation with our team of experts. If you are thinking of working with a consultancy on a technical project Datahub have successfully delivered projects in retail, aviation, healthcare, education, logistics.

Contact us
Contact us | DataHub Consulting
Datahub Consulting Website
Data Consultancy Services | Datahub Consulting

Find out how we can help

We do not employ salespeople; our team are all experienced technical specialists that can talk you through any of our services.

Contact us