What are some effective strategies to collaborate with business stakeholders on database projects?

Clear communication is key but also spending time understanding the needs including any systems, processes, the day to day for workers. These are imperative for the project to be successful. Not having a clear understanding in my opinion is a recipe for disaster. Working groups with various teams that the change will affect is important as their perspective will allow for ease when implementing.

I can only comment on Data Warehouse projects, but the single best collaborative technique is the Bus Matrix. This clearly maps out the business processes (Facts) and their analytical relations (dimensions) so everyone - very much including business stakeholders - can see and comment on the scope AND status of the deliverable, the correctness and completeness of the design. It is a great tool to give context to what is being delivered, as well as the when and the why.

Simple answer… It’s called communication… Define objectives… flash it out with your staff… get everyone on board… Inspire creativity. I’m sorry to me this is 101 stuff.

A database project exists on the basis of there being a need to create/capture/receive and store data. This need is usually stemming from business operations and there is no better way to know what the requirements and best deliverables of the project are without consulting stakeholders especially personnel part of that business function. The knowledge of their operations can greatly help on knowing how to deliver valuable, useful and function fulfilling database projects.

Document the current state. Meet with all the user groups involved, watch them do their jobs and and document what they do regarding people, processes and technology, showing all the hand-off and relationships. Then have them validate it.

If you’re asking for free analysis, good luck… having retired from a career IT… I’m sorry free advice is not always the best. Oh my God, I am in a form that requires me to put in more words that you may want to hear… Sometimes short answers have the best and concise… You may want to change your fourm

Database projects must be delivered in chunks or versions and so iteration is key. The end users and testers input shed light on aspects not necessarily considered in development or perhaps bugs. Some of these enhancements take more time to evolve without the end user ‘challenging’ release versions the way only they can. AGILE methodologies ensure steady progress in the right direction, a step at a time, without the need to halt database functions. These are inherent benefits of an elaborate and effective stakeholder engagement and Agile teams.

In my experience, after release training and support is often one aspect that could be improved. It can determine the longevity of success of the solution. A cost effective ready option are the end user testers and in-house champions who have engaged with the process right through. Alternatively short ‘how to’ videos and ‘traditional floor walking’ to visit consumers taking up new technologies, are valuable hands on training where possible

Beyond the project, you need to establish the governance of this database, assemble the right team to look after it BAU and keep stakeholders and contributors engaged.

Apart from all the above, in my experience, strong documentation is also very important. Documentation should be up-to-date and should be well communicated with business.

My experience is shaped from a database migration project (Oracle to SQL), especially when you have thousands of store procedures to convert from a legacy system. You must determine which migration strategy (One-Go or Phased Migration) is most appropriate. Also vitally important to consider in giving a taste of what's possible to the stakeholders after the migration.

As with most complex solutions like database development projects, my best tip would be to keep communication simple, clear and relevant.