Q6FSA Approach - A Data Department

Data is not a project or initiative, it is a business function in its own right.

The management of enterprise information is not a trivial matter, it requires focus, resources, budget and organisation. Yet, despite the repeated and justified calls from data governance and management practitioners to take a more holistic view, businesses are generally still viewing data as a project.

In many ways, this is due to how we are "selling" it. the data governance and management industry is fragmented with lots of disciplines, multiple view points and partial solutions. We don't play well together, and business can see this...so it is not surprising that business is wary of commitment over and beyond dabbling around the edges.

To begin to solve this stalemate scenario, let us look at how business arranges itself to get things done in other areas to see if we can find a blueprint for The Data Department. We need to find a business function that touches the whole enterprise, is seamlessly integrated with all business structures and operations and is found in every enterprise.

So, let us look at the finance department...and see how it combines a centralised financial system of record with federation of roles, processes and metrics to produce an enterprise wide view of the current and future financial state of a business...and of course, how the Q6FSA method and platform can enable a data department to do the same.

Part 1 - Is finance and data a good choice for this comparison?

Firstly, let us ensure that the comparison between finance and data is viable from an enterprise business perspective...or, in other words, that we have enough core overlap to make that case.

Enterprise field of scope

Both are undoubtably enterprise wide in nature, having a significant footprint across all enterprise operations.

Direct business value

Both provide a costed service to the business but do not directly create business value, they enable operational efficiency and reduce compliance risk. Therefore they have a similar goal of providing this service across the entire enterprise at minimum cost.

Governance and compliance

Both carry governance and compliance obligations, have control organisations and processes to mitigate risk and have legal requirements to adhere to legislative directives that are often territory specific.

Organisational structure and federation

Both have the need for a strong CxO mandate, require a centralised organisational structure to manage group operations and also federate processes and activities to all business functions to be able to achieve full coverage. Neither can achieve their purpose without enterprise wide collaboration and buy in.

Enterprise Cost Profile

Both have a direct headcount number and cost which is small compared to the business as a whole, but also "borrow" time and resources from the wider enterprise to complete their mission...they have a similar hidden cost footprint due to being reliant on the federation of activities and neither can complete their functions without incurring that cost.

Baselining the current and managing transformation

Both need to be able to create an as-is picture to provide the current state of their functional domains and also need to be able to predict trends and provide future operational insights. Further to this, they both are directly involved in ensuring that business transformation provides value, finance from cost and data from architectural efficiency.

Discipline based methods and standards

Both are discipline based functions, they operate under an umbrella of a set of industry approaches, best practices and standards.

Putting all of these aspects together, we can see plenty of overlap between the two, the main differences are the business artefacts that are being managed and the skills and processes being employed. So on this basis, we will push forwards as this being a viable comparison...if you don't agree...then place a comment and read no further...

Part 2 - Do this without a system of record, you're 'avin a laugh!

It would be a brave person indeed that approached the CFO of a global business with a suggestion of running their entire enterprise finance operation using desktop spreadsheets and visualisation tools. It would be a very short meeting...and possibly career.

No, the CFO will demand and rightly expect full integrated enterprise system coverage. It is not a matter of choice, it is expected to be there by default. This does not mean that finance is any more important than data from an enterprise perspective, just that finance is able to assert its mandate more effectively.

In this matter, the CFO has the full support of the information technology industry, big name vendors are queuing up to provide such a holistic capability and due to the strong buying power of the CFO within their own domain, coverage of all his/her needs can be met through a large choice of integrated systems designed specifically to provide maximum coverage.

The CFO has no problem spending 10s if not 100s of millions putting this all in place and keeping it up to date. It is just done. Period. No questions asked.

So then, that same plucky person goes to the CDO with the same suggestion and for some reason, gets a completely different response. Spending even a few hundred thousand on a comprehensive system of record for all things data appears to be an unachievable dream, a unicorn, rather than a necessity. Millions...forget it! The suggestion of doing it all in spreadsheets (always for the moment, not longer term of course!) gets a warm reception.

"Let's get some quick wins!" says the CDO, "I'll see if I can get some budget together to put together a small pilot project, test the water and see if this will fly...we don't need to bother the business people too much, do we?".

"No! Of course not!" says the plucky person, filled with enthusiasm. "It's all on my desktop, but I can put it on the Wiki if anybody wants to look at it! They could even create a dashboard if they download it all and muck about a bit!" says the plucky person, now positively incandescent with excitement.

The mention of "dashboard" causes the CDO to smile and nod approvingly...both leave the encounter with a fabulous sense of progress and a job well done...

This may be a rather flippant example, but how many times have you experienced this in reality as a data practitioner trying to get something achieved? If it's not every time, then it is more times than not.

The difference here between the two responses is mandate, the CFO has one by default, but the CDO has to always beg, steal and borrow for one. Yet, the need for a comprehensive system of record for both is the same, possibly greater within the data space as data is an enterprise enabler more than finance across the enterprise...I would say a system of record for data has a greater enterprise ROI.

And the issue here is that the same information technology industry's support for the data department is much less coordinated. Full coverage is hard to find in the enterprise data space, nobody can agree what approach to use and therefore it is much harder to see the end game from the enterprise perspective.

The Q6FSA approach to the system of record for the data department is therefore to provide a platform more akin to a full coverage data ERP. To offer the CDO a similar comprehensive choice to what the CFO gets, a turn key method and one stop shop for all things data, available for the whole enterprise to use.

Part 3 - Establishing the data department organisation.

Walk into most business headquarters and you can pretty much find the group finance department with very little effort, it will probably be signposted on every elevator, and once found, you will most likely find all its sub departments operating at group level in the same place. It has an established identity, location and form. You will also find that its operations are well defined, its roles and disciplines generally understood and its purpose clear.

Now try and find the data department...and you'll be looking for a needle in a haystack, I'm afraid...chasing a ghost function with little or no identity. Yet identity and clarity of purpose is key to establishing a business function's place in the wider enterprise, so the data department must find a way to become definitively recognisable.

Unfortunately, one can not get away from the fact that having a clear physical location for the core data department (the bits that need to be centralised and not federated) gives it a greater sense of existence and strength in numbers that the finance department takes for granted. Getting that signpost on the elevator means legitimacy, and with legitimacy you get power and mandate.

Now let's assume the CEO bites on this and creates a space for the data department the same size as the one afforded to the CFO in the group headquarters and the signposts are added to the elevators...

You need a figurehead to front it, one who sits shoulder to shoulder with the CFO in the boardroom and is able to secure budget, resource, mandate and gain enterprise wide inclusion just as easily as the CFO. Somebody to put finance and data on the same level. A true CDO with teeth to establish the data department. If you don't get this, forget it!...The beg, steal and borrow plan just doesn't work at the enterprise level...

...but assuming you do...the next step is to gather all strategic data practitioners from all EIM disciplines that have been spread around the business and also buried in projects and transformations (Governance, Privacy, Architecture, Modelling, Analytics etc) and place them in the data department together, so they, for the meantime, are owned solely and accountable only to the CDO, but still supporting their existing commitments. To the outside world, you now at least look the same as the finance department next door, even if you don't operate the same way.

The next stage is to establish your complete operating model across all data disciplines, a thing that comes naturally to the finance department within their domain. That operating model should, like finance, support the roles and processes needed for baseline, insight and transformation activities. Make roles and responsibilities clear and focussed, arrange the department for collaboration and establish a single view of process. Create KPIs and measures to enable the CDO to show the same level and quality of quarterly executive reporting as the CFO gets...establish the data department as any other group business function...create identity and purpose...get your own house in order first.

This set of activities should not be rushed, there are no quick wins here, the CDO needs to be strong and consistent in message...no group department can provide enterprise value without first establishing identity, method and purpose...

The Q6FSA method and platform places the operating model at the heart of the data department, formalising it as an enterprise resource portfolio of people, roles, decision authorities, interlinked processes and task collaboration.

Part 4 - Tool up, rehearse and perfect.

As stated at the start of this article, for your newly designed enterprise scope data department operating model, you need an enterprise class set of tools to run it. You have already done the hard work, you know what you need your tooling to do to support your entire scope.

You have to think big, aim for full coverage and take your own advice that you would offer to the business under these circumstances...don't create silos, don't duplicate capabilities etc. After all, it would be quite embarrassing to create an unholy tanged spaghetti mess in your own back yard. Remember, you are now thinking like the finance department, this is your right and not a nice to have...this is your system of record and your future success depends on it.

During this tooling selection process, all data disciplines must be treated equally. There should be no bias to any particular discipline, method or technology...because your global enterprise probably has need for all of them somewhere.

So going "full enterprise", these are the characteristics you should be looking for and not compromising on:

Deployable at enterprise scale

There should be no technological or commercial barriers to full enterprise roll out. Like the finance system, the user community will be large, maybe into the 1000s, covering not only the data department itself, but also business sponsors and governance, transformation programmes...the whole shooting match. Any tools or frameworks that can not operate at this scale should be discounted.

Separation of concerns at enterprise scale

Beware the tools and frameworks that have come from a single desktop user, see and change everything background. There should be comprehensive fine grained role based access to both what can be done and what can be seen. Oversight should be built in.

Repository driven - top down and bottom up

Ideally, like the finance department, you should strive for a single repository solution, whether provided by the chosen tool(s) or easily created and accessible from all of them. Such a single repository should include both architecture led top down design and bottom up discovery and re-engineering. It should be a living repository able to quickly baseline the current state and facilitate forward change across the entire enterprise information landscape, across 1000s of applications and data stores and 10s of 1000s of data structures.

Having a repository means that you can also reduce your architectural and design documentation workload, the repository is the documentation, governed, life cycle managed and version controlled. The enterprise user community should access the repository for everything they need, just like the finance system.

Federation and collaboration at enterprise scale

There are 10s of not 100s of different enterprise stakeholder roles that need to collaborate seamlessly, that come from both internally within the data department and across the wider enterprise. Each will have a specific need and footprint on the your tooling platform and your single repository. This is not a one process fits all scenario. The right roles must do the right things in the right order with the right governance, right across the entire business.

Multi-disciplinary, multi-method with full enterprise information coverage

Finance has many disciplines, so does data, your new internal data department operating model should have identified where they connect and interact already. However, looking at many data related tools in the marketplace, not many operate without bias towards a specific discipline, method or approach. This can be very subtle and difficult to spot until you use them in anger, so to speak. Show stopping limitations at full enterprise coverage need to be avoided.

We need to look for tools and platforms that are data focussed, not so generic that they are "jacks of all trades and masters of none", but are designed for data, agnostic to method, hype, domain and technology, tools that can take all the variety of the entire enterprise information landscape at deep dive, any data technology, any data language and structure, any approach and leave nothing behind.

Portfolio, time, resource, priority and cost aware

Just like the finance department, you must be able to manage your people, skills, time and prioritise your workloads and deliverables. This becomes much more efficient when you combine your operating model and transformation engagements with the data artefacts that you are discovering or changing. Adding integrated full portfolio and project management to your tooling framework criteria allows you to operate as a separate and fully autonomous delivery and governance organisation.

Repeatable, traceable, measurable and consistent

The finance department will have pre-defined, standardised processes for engagement and interaction with the wider business. They do not make it up every time and neither should the data department. Any tool should be able to standardise and audit its operations, consistently apply and measure them and be able to guide the user community from start to finish through the process.

All these characteristics are necessary because, like the finance department, you are now running a full enterprise scope group business function and not a single project. So choose your system of record and the tools that support it wisely, and they will serve you.

Now, assuming you've done this and your system of record is there in place, empty, fully integrated if needed and ready for action...do not rush into full enterprise deployment, keep it internal for a while. Take time to practice your operating model with it in place as all the actors and roles, test the end to end collaboration and governance, rehearse the process and ceremonies. Become familiar with how everything links together, spot issues, improve things as you go...become an integrated unit...become the data department.

But do it at full volume, gather all your physical estate, every UI, every database, every process, every integration and establish automated updates, test performance and operations at full scale...volume test everything. If you fail at this point, you've chosen the wrong tooling...go back and look again...don't live with it. You deserve enterprise class, just like finance.

As you may guess, the Q6FSA approach and platform is a full enterprise scope, multi-discipline...and all the rest. Except...we still have some work to do on measurability, activity costing and inline data quality...it's best to be honest about these things :)

Part 5 - Federate and expand the operating model.

Sorry! You're not ready to launch yet because the data department can not do this on it's own, like finance, it needs to collaborate through federation...it needs to borrow people and their time. Up to now you've been keeping all this quiet, performing all the roles yourself and laying the foundations.

To the world outside the data department, nothing has changed, you have been continuing to engage as before...but they might have noticed all this operational improvement and internal collaboration focus has sharpened you up a bit, data governance, privacy and architecture seems to be more coordinated...and they know where you all sit.

Take time at this point to focus on the operating model again, look at your tooling capabilities and identify the roles and process steps that you can lift outside the internal data department. The goal here is that the more you federate, the more time you are borrowing, the more you can get done.

Also, your choice of tooling should ideally have not created overly manual, skilled or documentation heavy process steps that should be federated, things you federate outside the data department should require small amounts of borrowed time that can also be delegated and reassigned. The tooling should do the heavy lifting, the data department the heavy processing. Those small amounts of borrowed time, over the enterprise as a whole, adds up and this is what creates the ability to do lots of work very quickly.

The model again here is the finance department, they only do core processing, it's the budget holders and other business stakeholders that generate most of the financial artefacts. You must think in the same way. You must assume whatever you federate to them, they will make time for as the CDO has the mandate to make it so. The CDO can do this because the burden on each individual is small. You must assume that a business data steward defining quality rules for a planned data structure is exactly the same as a business manager defining and submitting a 12 month forward budget.

The Q6FSA method and platform supports fine grained assignment and execution tracking of both internal and federated data related tasks, it is an enterprise scale PPM tool, configurable to the roles and organisation structures of the entire enterprise. It enable you to define and run the operations of the data department.

Part 6 - Document, engage and mobilise.

Now, we'll assume that when you created your new combined operating model and worked on the tools...you also documented it...created user instructions to help business users and new starters engage with ceremonies, processes, tools and system of record...prepared Wiki pages and IT support documentation. Of course you did! Or if not...now is a good time!

The important thing now is posture, the data department is not selling this to the business...the business is adopting it as default, just like the finance department, the mandate is set, there is no option.

Again, if your tooling and system of record choice was wise, you can start anywhere and everywhere at the same time. Clear the decks in your system of record, initiate automatic development environment capture of your current data landscape, then overlay with the automatic production system equivalent. This creates a set of committed and planned artefacts as your baseline, now identify ownerships and generate and assign operating model process tasks for the entire landscape into your data department portfolio and project management framework.

Now tell the whole enterprise that the data department is officially open for business and that their tasks are ready and waiting for them. Obviously, they are new to this so initial momentum will be slow...and many questions will be asked and support will be initially intensive, but it will pick up as the business learns their part in the end to end process.

Remember, you have chosen the operations that you federate wisely, you have made them small, repeatable, clear and focussed, you have practiced them yourself, so you know they work. Over time, as maturity grows, so will the number of operational steps that you can federate and the more time you can borrow.

Federated business as usual baselining, classification and governance activities will most likely pick up slowly...transformations and business data initiatives will need to plug in and engage more rapidly to meet specific deadlines.

There will be push back, stay strong and let the CDO flex muscles and bang heads together for the greater good.

Work the operating model, measure completeness and maturity, prioritise, continuously refine and improve and spread the good news of what has been achieved with your repository and PPM metrics at the executive board reporting cycles. Rinse and repeat until the you are managing only change and transformation moving forwards.

This is the Q6FSA approach to becoming a data centric enterprise, not a project and nothing to do with dashboards...

The data department.