In twoday kapacity, we have tasks ranging from full project deliveries, joint deliveries with our clients' data teams, and tasks where we deliver partial deliveries into larger programs. Project planning is always done together with the client's team, and the theme of how to approach "the successful data project" is discussed both early in a customer journey and along the way.
Whether it's an AI (Artificial Intelligence) project or a more traditional data and visualization project - such as an analysis solution for a sales organization or a finance department - the key to a successful project is rooted in strong involvement and anchoring in the part of the business that needs the solution.
In a previous blog post, we wrote about the importance of good cooperation between those who make the analysis solutions and those who need them. From our experience, the key to getting value out of a data project is precisely good cooperation.
The first important factor for a data project that ultimately creates value and makes the organisation handle tasks differently is business ownership or sponsorship.
When twoday kapacity works on data strategy for a client, the ownership of a data team and a data platform is often a topic of discussion. Initially, it is not the organizational affiliation such as finance or IT that determines the success of a data project. Instead, the business sponsorship - the support for a common data platform, a common analysis and reporting truth, and some common governance standards - is crucial.
This sponsorship should be shared by the key business stakeholders if it is to have full effect. This could be in the form of a data platform steering group or a Data Board, where the management of the business area, that is the focus of a specific project phase, comes forward and joins a project steering group to be replaced by another when the next phase begins. Such a setup for sponsorship ensures that there is always focus on the big picture, the company's strategy and focus areas, and direct involvement of the business area participating in the specific delivery.
Involvement of the business
Our recommendation to our clients is always to try to establish a consistent approach to the data project phases that need to be delivered. Therefore, it can be advantageous to develop a model for receiving analysis/reporting needs, prioritization, specification, delivery, testing, training, and go-live. We recommend this because both we, the client's own data team, and the receiving business units need a framework for working together on the solution. Additionally, it ensures that all participants have aligned expectations for effort, roles and responsibilities, as well as the content and timeline of the delivery.
That being said, it is very important that the collaboration between those who need analyses and those who will produce them is based on direct dialogue. Templates are useful as a daily help, but direct dialogue - not second-hand handovers - is necessary to ensure that the need is properly understood. Only with this approach can we ensure that the solution delivered meets the need and is also designed for future expansions and additions.
In other words, twoday kapacity's experience is that detailed requirements gathering is a bit of an art form, which pays off to invest in building skills and executing with time.
twoday kapacity's recommendation for solution development is an agile project approach, where the solution evolves over time. This also means that the involvement of the business, which is so essential, will be ongoing so that the final tested solution fully reflects the dialogue and desires that the business has contributed throughout the process.
In twoday kapacity's project delivery method, we work with two important milestones: Technical Go-live and Business Go-live. The technical go-live is when the solution has been fully developed, tested, approved by the business, and moved to the production environment. The business go-live, on the other hand, is when the users have received the solution and can use it for its intended purpose, as originally envisioned by the business sponsor. Additionally, there must be a support setup to support its use. In other words, between these two milestones, there are a number of training, anchoring, and communication activities that are essential to ensure that the solution generates the value that was originally intended.
twoday kapacity's recommendation is that the deployment plan is created and communicated at the beginning of a project phase - this provides reassurance that future users are aware of "what is going to happen" early on, as well as the support options available before they start using something new. If there are already processes for change management, they can be used for this purpose, but otherwise, a practical approach with a timeline for these activities as part of the project plan is also a way to approach the area.
It is also worth investing in developing a consistent approach with templates for, for example, what needs to be communicated to whom, when, how training should be developed and held, and how support should be handled both immediately after deployment and in the long term. It may cost a little extra during the initial phase, but it will make things much easier for the later phases. It also helps to develop a "precedent" for the way sponsors, business units, and data teams work together, which makes expectation management more effective.
For many companies, a roadmap for a data solution will include both strategic and technological considerations and is therefore often seen as a larger project. twoday kapacity advocates that when embarking on the work of a new data platform, a "Roadmap-light" should be developed. An overall plan that ensures the establishment of a management governance structure, a delivery model, and an approach to rollout, ensuring that the work starts with the best setup for future successful use of data.