Connect the target Operating Model, desired Capabilities and specific Capabilities properly to express control and success.
Start at the start - exam how your remit connects with the wider internal strengths, weaknesses and external opportunities, threats in terms of political, economic, sociological, technological, legal and environmental aspects. Then build out the team and operating model/way of working to be able to deliver the current and future remit.
There seems to be no stakeholder that doesn't want data. This Effort-Value Priority grid can sort out the agreed cascade. Current resources, IT infrastructure, issues of linking into other areas, legal and privacy requirements, urgent upgrades and practical considerations will shuffle these into a Roadmap. Story Points links into Sprint Sizing.
The more capabilities that land, the more the time is needed to provide BAU (business as usual) and Fix-on-fail support.
It's worth creating a RAID document to gather up issues that may affect the tasks; risk (chances of it happening v Size of issue if it does), assumptions, issues, dependencies.
The steering committee (SteerCo) would review and signoff the priority, (RAG) progress and resources.
The skill of leadership is how to balance all the demands and provide a quality output on time. The Iron Triangle (pictured) shows the main choices. Lets face it “Good” shouldn’t be optional.
I prefer to create a quick, fit for purpose version 1- to test against need and changing specs, jumping quickly over time sinks and gathering technical debt to put into a version 2 which will on time, robust and flexible.
Capabilities are made up of various distinct deliverables. Efficiency can be found where a deliverable can elegantly serve more than one capability. Projects go through many stages, from coding to hypercare which can be tracked via ticketing /scrum /kanban /wagile method.
Each part of the project could have different stakeholder with different levels of interest, which should be gathered in terms of RACI (responsible, accountable, consulted, and informed).
A very useful grid that defines to refine which tasks should be accepted. Requests for resource should be well thought through and not ad-hoc demand to move a task out off their inbox.
Types of Data Masters
Data Masters come in different flavours with their own responsibility to ensure data is governed properly. There isn't perfect a one-size-fits-all data governance framework that works for all organizations. It's best to form a bespoke collection of responsibilities or supporting actors. If in doubt, start with the (yellow) those who pay, collate or use it, own it but they should lean into Stewards with specialist skills (green) and align with corporate rules and adhere to laws and norms. The IT (blue) data masters are important but they aren't the default Owners.
Rumsfeld Matrix can be used to help with:
o Prioritizing tasks: By focusing on the most important areas of indecision
o Allocating resources: By concentrating on the most crucial areas
o Collaborative communication: By facilitating communication among professionals
o Making informed decisions: By identifying and addressing gaps
o Leveraging hidden insights: By preparing for future uncertainties
Each person works 38hrs per week, 20 days a month, 225 days a year. There is rarely enough resource to do everything, in fact businesses are geared to ensure only the acts that give a financial return is achievable. Focusing on the Need. Agile enables complex deliveries of new capabilities in timely and reliable manner. Only important asks will enter the sprint without being planned in. Red lines from Legal or Compliance come first, closely followed by VIP requests. Time must be ringfenced for 1-2-1s, Training and Washups. All asks can go onto the backlog but this does not mean they will be selected for a Sprint soon, without line-manager support to change the roadmap priority. The more new builds delivering new capabilities, the more BAU time probably required.
Ceremonies include:
o Planning: Sizing and selection the tasks. Never load more than 70% as unplanned happens: red lines, more BAU needs, sick leave.
o Sprint: Focusing on delivering known tasks within the 70% of 2-week period
o Daily Scrum: Quick alignment on progress, focused on unblocking
o Sprint Review: Reporting Sprint outcomes to stakeholders (external)
o Sprint Retrospective: Reflecting +ve/-ve aspects of Sprint (internal)
o RAID (Risk, Assumptions, Issues, Dependencies) can also include downstream Decisions and Actions.
o Issues are more important than Risks.
o RAID logs/meetings tend to become unwieldy, unfocused and only deal with a few rather than the many.
oThis schematic of a thought through process encourages prep, enhanced understanding and aids better decision making.
o RAAIDD Logs collate core information, prepared by experts/owners, should be informative and succinct.
o RAID meetings should check and calibrate inputs, cross examine expert evidence, drill into dependencies and set actions/expectations. against current roadmaps. They should be frequent and focused on decisions and reviewing outcomes.
o Not all Issues or Risks will be actioned due to other priorities – they may be monitored or the risk accepted compared to the likelihood/cost.
Risk is the product of, how likely is it to happen and then how bad will it be if it does. An important part of understanding which issues/risks to invest a solution in. This awareness, compared to cost (expenditure or income) will help decision makers to action a resolution, create a plan to resolve, wait for more information, or to ignore/absorb the issues.
Data has it's specific Governance needs.
Agile is a project management framework that originated in software development but is great for getting technical teams to chunk through complex/technical/broad projects effectively/efficiently with flexibility and transparency. It enables focus on the start>end of each part with quality, and ensuring it fits into the larger project jigsaw correctly – delivering what it should. It enhances continuous collaboration, adaptability, and client understanding.
The Agile Manifesto consists of four key values:
o People first: Individuals and interactions over processes and tools.
o Focus: Working software over comprehensive documentation.
o Collaboration: Customer collaboration over contract negotiation.
o Adaptability: Responding to change over following a plan.
To achieve this:
o Management needs to buy into the space needed to use intelligence. Create aircover to enable the larger, long term important builds by buy in.
o The wider company needs to follow the right Backlog process to ensure every new thought is given its correct priority and value.
o BAs need to think about how specs will align to how/who, the proof of done and how to stitch together.
Although the wider team dynamic is agile, this can be seen best when there’s team greater than 5. On a personal level, and even in a wholistic view the process may seem Waterfall, so some may use the term Wagile.
From on-prem excel to big data in the cloud, but usually a complex, complex hybrid. Plan for the future as it’s expensive and takes time to pivot. Privacy controls here are vital – data democracy does not mean everyone gets access to everything.
The big 3 cloud platforms (amazon webservices redshift, google cloud platform, Microsoft's Azure) all provide great expandable and powerful options to keep future ready.
IT may have already chosen a supplier. Data Architects will be able to explain the pros and cons compared to the needs of the operating model.
Most data systems can be described as a network of boxes and connectors. I use a plumber metaphor as the data flows around the system.
Each box (platform) needs to be understood in terms of what it contains in terms of table schema, the rules of selection, the variables that are being sent, the permission to use, the cadence, how received data is QC'ed and matched in.
Legacy process and platforms will need to be replaced, which is not simple or cheap. Data lasts longer than platforms but code should last 3+ years without major revisions. This schematic will help manage out unforeseen outcomes when aligning the new connections and cut-overs.
Pipelines and APIs will fail. Code can be turned off or changed without testing and without warning and flush poor or ghost data downstream though the system. Record and map where the issues stem from, reinforce controls and consider replacing where issues recur. It may not be your fault but it is your problem.
A hard-earned list of some of the many issues that can prevent a pipeline from working. Most issues could have been avoided by including specifics in a tight data spec or ensuring that the build was checked off against the data spec.
We need your consent to load the translations
We use a third-party service to translate the website content that may collect data about your activity. Please review the details in the privacy policy and accept the service to view the translations.