Dummy’s Guide to Data Management

7 Tactical Steps to Structure Corporate Chaos

This guide is long. That’s because it actually solves a real problem.

If you manage projects and deal with data chaos, stick around. This will walk you through seven tactical steps for bringing structure to the madness:

1. Identify the Problem

2. Recon the Data

3. Develop Courses of Action

4. Evaluate Options and Decide

5. Manage Risk

6. Implement the Solution

7. Supervise and Refine

Keep scrolling or use Command F to jump around.

It only took one text and a few disaster stories to realize just how badly we need a dummy’s guide to data.

An Army buddy recently asked me: “Dude, can you write a dummy’s guide to data? I’m pretty sure half the people out here think ETL is an energy drink.”

Fair enough. For a lot of us who transitioned into project or program management, dealing with data and change management feels like running a convoy with no map, no GPS, and no comms. Everyone has their own direction and their own priorities, and you're just trying to keep the whole thing from falling apart.

In the Army, at least we had a clear mission, a commander’s intent, and a process that everyone followed. On the civilian side, it’s like the operations order got lost in someone’s inbox. People are off doing their own thing in their own swim lanes, and nobody is coordinating. The result is that data projects stall, blow up, or quietly die. For example:

• Target’s infamous data breach (2013). Target had a full data team and cybersecurity measures, yet attackers still compromised millions of customer credit card details. The breach exposed huge gaps in their data management practices and cost them almost $300 million in damage control and reputation.

• Hertz’s digital transformation fiasco (2019). Hertz hired Accenture for a massive tech overhaul, only to have miscommunications and an overly complex plan drive the project off a cliff. Hertz filed a $36 million lawsuit against Accenture after the project collapsed under delays and cost overruns.

• Knight Capital Group’s $440 million oops (2012). A rogue algorithm was deployed during a software update with no proper testing or version control. Within 45 minutes, it racked up nearly half a billion in losses.

In each case, the breakdown came from poor data management and a lack of structured planning. And this isn’t a one-off problem. Studies from McKinsey estimate that around 70% of major digital transformation projects miss the mark. It’s not because the tech doesn’t work, but because the people and processes around it fall apart. Without a clear plan, even great teams with great tools end up spinning their wheels.

So what’s a project manager to do?

Apply some military-grade planning. The Military Decision-Making Process (MDMP) that keeps a brigade’s operations on track can be repurposed to whip chaotic data projects into shape. MDMP is a proven 7-step framework the Army uses to plan missions and make decisions. It’s robust, repeatable, and battle-tested – literally. In the business world, meanwhile, we have a grab bag of frameworks (Balanced Scorecards, SWOT, Six Sigma’s DMAIC, you name it), but no universal standard for planning and executing data projects. It’s time to change that.

In this guide, you’ll see how you can use MDMP to manage corporate data initiatives like a field operation. We’ll also do a quick refresher on some data basics along the way, so you know what you’re wrangling.

What Is Data, Anyway?

First, let’s make sure we’re speaking the same language about data. At its core, data is just raw information: the 0s and 1s, text, numbers, images, or any facts and figures that flow through a system. By itself, data is about as useful as rations locked in a storage container. It’s what you do with it that matters. You need to process, organize, and interpret data for it to have any value.

Here are some of the key data concepts every PM should know:

• Data Management: Organizing your data so the right info reaches the right people at the right time

• Data Engineering: Building and maintaining the pipelines that move and transform data. Think of it as laying roads and bridges for information

• Data Analysis: Turning raw data into usable intel like charts, reports and trends

• Data Science: Using modeling, statistics, or AI to forecast and experiment. If analysis is intel, this is your R&D shop

• Data Governance: The rules of the road. Ensuring data is accurate, secure, compliant, and consistently defined across the organization

• Decision Making: Actually using insights to choose a direction

• Problem Solving: Taking action based on those decisions

• The 5 V’s of Big Data (What you’re really managing)

  • Volume: Massive quantities of data (terabytes to exabytes) that require distributed storage and parallel processing

  • Velocity: The speed at which data is produced, ingested, and must be acted on; drives streaming and real time analytics

  • Variety: A mix of structured, semi structured, and unstructured formats (tables, JSON, images, audio) that demand flexible tooling

  • Veracity: The reliability and accuracy of data. Poor quality or inconsistencies degrade downstream models and decisions

  • Value: The business impact or insight extracted. Reminds teams to focus on outcomes

• Bonus V’s (You’ll hear these too)

  • Variability: Sudden spikes or shifting meaning in data

  • Visualization: Communicating insights clearly to us humans

  • Validity: Statistical soundness or trustworthiness of models

  • Vulnerability: Data security and privacy risks

If you’re thinking, “Alright, I get the basics, but how does this help me in my job?” Don’t worry. We’re about to translate these concepts into a step-by-step battle plan for your data projects. It’s time to bring in the MDMP framework and structure your approach to corporate data chaos.

MDMP vs. the Data Dumpster Fire

In the Army, when you get a mission, you have a clear objective, a commander’s intent, and a structured planning process. In corporate life, project charters and kickoff meetings don’t quite measure up. One day you’re told “We need a data lake” or “Implement this new analytics tool ASAP,” and you’re left wondering what the actual mission is. There’s no wonder it feels like chaos.

Let’s break down the problem:

• Lack of a Standard Framework: The military has MDMP (documented in exhaustive detail – ever seen a 156-page planning manual? Fun times.). Businesses have some planning tools, but they’re all over the place. One team uses OKRs, another uses some consultant’s fancy 5-step method, and neither covers the full picture for data projects. There’s no common playbook, so everyone wings it.

• Multiple Stakeholders, Fuzzy Goals: In business, you’re juggling multiple “bosses,” that may include executives, department heads, IT, maybe an external client. Each has different priorities and KPIs. Without a single mission objective, you get scope creep and confusion.

• Data Overload & Siloes: Unlike in the military, where intel is filtered through a chain, companies often have data everywhere. Different departments hoard their own spreadsheets and systems. One unit’s “customer” is another unit’s “client,” and they might not even realize they’re the same person because definitions differ.

• No Risk Management Plan: Businesses know risks exist (cyberattacks, regulatory fines, project failure), but often address them after a crisis hits.

Given all this, it’s clear why corporate data projects often falter. But enough doom and gloom. Let’s talk about a solution: the Military Decision-Making Process. MDMP is systematic, extremely thorough, and adaptable. It forces clarity at every step, from identifying the real problem through executing and refining the plan. We’re going to adapt MDMP into a seven-step guide for your data projects.

1. Identify the Problem/Opportunity (Receipt of Mission)

2. Recon the Data (Mission Analysis)

3. Develop Courses of Action (COA Development)

4. Evaluate options and decide (COA Analysis through Approval)

5. Manage Risk (Risk Management Process)

6. Execute with discipline (Troop Leading Procedures)

7. Supervise and refine

Let’s break down MDMP for the corporate battlefield.

Step 1: Identify the Problem/Opportunity

Every mission starts with understanding what you’re trying to accomplish. In the Army, this is the receipt of mission, where you get your orders and clarify the task at hand. In the corporate project world, this first step is usually murky. You might get a vague directive like “improve our data quality” or “implement AI analytics.” Before you charge up any hills, you need to clearly define the mission.

Begin with a simple gap analysis to nail down the problem or opportunity in concrete terms. Essentially, ask and document: Where are we now? Where do we want to be? What’s the gap? I like to sketch it out visually, for example:

Current State: Data in 5 different silos, and no single customer view

Gap: Inefficiency; lack of visibility

End State: Integrated database with 360° customer view

The conversation on gaps like these—especially with the help of a whiteboard—works wonders. It forces everyone to agree on the current state (the ugly reality), the end state or objective (the dream scenario), and what’s missing in between. It brings clarity and a shared understanding of the mission. In military planning, we’d also clarify the commander’s intent: the underlying purpose or desired outcome. In corporate terms, figure out the business leader’s true intent as part of the end state: Increase sales by X%? Cut costs? Improve customer satisfaction? That’s your North star when trade-offs come up later.

Take the time to talk to stakeholders and ask annoying questions if you have to: What problem are we really trying to solve? Sometimes you’ll find each person has a different answer. Getting alignment up front is crucial. It’s much better to sort out conflicting objectives at the start than to discover halfway through that marketing and operations had totally different endgames in mind.

Bottom line: Define the mission explicitly. Don’t rush this step; a shared definition of the problem or opportunity is your foundation. If you skip it, everything else you plan could be aiming at the wrong target.

Step 2: Recon the Data

In the military, after receiving a mission, you gather intelligence and assess the situation. In a data project, this means collecting and analyzing all relevant data and facts about your current environment (systems, processes, pain points, etc.).

Here’s the kicker: in business, information won’t come nicely organized. Data is scattered across databases, spreadsheets, and Bob’s secret SharePoint site that no one else knows about. It is likely siloed, inconsistent, and incomplete. So, your job as PM is part detective, part diplomat:

• Figure out what data you need. What inputs will drive this project? If the goal is a 360° customer view, you’ll need data from sales, marketing, customer service, maybe external sources. Identify those early.

• Find out where that data lives and who “owns” it. This often means venturing into different departments. (Pro tip: bring donuts or coffee when asking another team to share data.)

• Align on data definitions. This is huge. If different groups use the same term to mean different things, get everyone on the same page now. Finance’s definition of “active customer” might differ from Marketing’s – reconcile it now or you’ll have disputes later.

• Assess data quality and gaps. Is the data complete, up to date, and accurate? If you discover, say, that 30% of customer records lack an email address, that’s a gap to fill or a limitation to plan around.

• Start collecting the data (or setting up pipelines) and make it sharable. Often this involves some quick data engineering: connecting systems or automating exports. The less manual, the better. You want a reliable flow, not a one-time dump.

How do you actually do all this? Talk to people. Conduct stakeholder interviews, run a workshop or a “town hall” meeting with relevant teams. It’s basic, but you’d be amazed how much clarity a few candid conversations can bring. Ask the end users what data they wish they had. Ask the IT folks what data exists and how it’s structured. By gathering this information, you’re doing the corporate equivalent of scouting the terrain and enemy forces.

Expect to play mediator here. Different folks will want different things from your project – one manager’s “must-have metric” is another’s “who cares?” You won’t satisfy everyone 100%, but listening to all sides will help you architect a solution that addresses the most critical needs and at least acknowledges the rest.

Note: If during this step you uncover that the organization has zero data governance, no data dictionary, and a bunch of undocumented IT systems… don’t panic. That’s normal. You’re there to bring order, remember?

Step 3: Develop Courses of Action

Now you’ve got a clear mission and a bunch of intel on what you’re up against. It’s time to brainstorm how to accomplish the mission. In the Army, we’d develop multiple courses of action (COAs)—different ways to achieve the objective—before picking one. In corporate projects, this step usually gets skipped entirely. Under pressure, many teams latch onto the first solution that comes to mind (or the one the boss already hinted at) and run with it. Not you; you’re going to lay out some options.

Don’t settle for the first idea that pops into your head. Why? Because your first idea might not be the best, or it might only solve part of the problem. Generating a few alternatives helps you avoid confirmation bias and consider the problem from different angles. This is where a bit of creativity and healthy skepticism comes in handy.

Some ways to flesh out different COAs in a data project:

• Prototype different solutions. If the project is about improving data reporting, maybe COA 1 is building a data warehouse and fancy dashboard, COA 2 is leveraging the existing systems with some tweaks, and COA 3 is outsourcing the analytics to a cloud service. Sketch out each at a high level.

• Model or simulate outcomes. For example, if one idea is to centralize all data in a new system, model the time and cost it would take, versus a more incremental approach. Think ballpark estimates and potential impact, not a 50-page feasibility study.

• Wireframe the user experience. If the project involves end users (like a new self-service data tool), draw a quick wireframe or flow of how it might work. This makes the idea tangible without heavy investment.

• Good old brainstorming with the team. Get your core team in a room and say, “Alright, how many ways can we solve this?” Encourage out-of-the-box suggestions. The first few might be obvious, but the gems often come after you’ve tossed around a dozen ideas.

It can help to rank potential COAs by fidelity or effort. Best: a working prototype (even if minimal) that proves an approach could work. Next best: a detailed model or diagram. Lower effort: a simple PowerPoint proposal. Be warned though, PowerPoint is every corporate warrior’s default weapon, but it can give a false sense of certainty. (Amazon ditched PowerPoint in favor of written memos for decision meetings, because flashy slides hide shallow thinking.) Use slides if you must, but focus on substance over pretty fonts graphics.

The key is giving your decision-makers options. In the military, commanders hate when they’re presented with only one plan – it smells like a trap (“take it or leave it, sir, there’s no Plan B”). In business, your boss might say “just tell me what we should do,” but you can bet they’ll appreciate knowing you considered alternatives. Plus, when you have to defend your plan later, you can confidently explain why it’s the best course of action.

Military humor alert: If anyone questions why you’re spinning up multiple plans, feel free to quote the old maxim: “Two is one, and one is none.” It usually refers to gear (having a backup), but it applies to plans too. You always want to have an alternative ready. Develop COAs like your project’s life depends on it (it just might).

Step 4: Evaluate Options and Decide

This step is essentially COA analysis, comparison, and approval rolled into one. In MDMP terms, you’d wargame out each course of action, compare them against criteria, and then your leadership would approve one. In the corporate realm, think of this as stress-testing your options and getting buy-in on the plan.

First, evaluate each option critically. Ask the tough questions:

• What are the risks and downsides? Does COA 1 depend on unproven tech? Does COA 2 take too long? Could COA 3 upset customers or regulators?

• What are the costs versus benefits? Maybe COA 1 is expensive but yields a big ROI, while COA 2 is cheaper but with modest gains.

• How feasible is it, really? Do we have the skills, time, and resources for each option? Is one approach simpler to execute than the others?

Be honest here. No plan is perfect. In fact, this is a good time to do a mini risk assessment for each COA. Identify potential failure points. It’s much better to confront them on paper now than be blindsided later. You might even score each option (e.g., 1-5) on factors like cost, risk, speed, and impact to help compare.

Next, compare your options head-to-head. You can use a simple matrix on a spreadsheet if that helps. Maybe one option is superior in outcome but comes with higher risk, whereas another is low-risk but only partial impact. This step is akin to wargaming in the military: you’re mentally simulating how each plan might play out in the real world. Play devil’s advocate with your own ideas and poke holes in them before someone else does.

Now, select the best course of action. In the end, you (or the project sponsor) have to pick one path. In a corporate setting, this often means getting the approval of key decision-makers, like an executive sponsor or a steering committee. Package your analysis and recommendation in a digestible way. Pro tip: aim for stakeholder alignment, not total consensus. You’ll never please everyone, and trying to do so can stall the decision indefinitely. Instead, ensure the key players (the ones with decision authority or budget control) understand the recommendation and agree on it.

One more thing: document the decision. In the Army, once a COA is approved, it becomes the basis for the operations order. In your project, make a simple memo or deck that says “Here’s what we’re doing and why.” Include the objective, the chosen approach, and high-level details of scope/timeline. This is your “orders brief.” Share it with stakeholders to reset everyone’s understanding. It will save you from the “I thought we were doing X instead” confusion later.

By the end of Step 4, you should have a chosen plan of attack, with leadership buy-in. You’ve effectively done the hard thinking upfront, which sets you up nicely for execution. As any vet knows, a decision is not the end; it’s where the real work begins.

Step 5: Manage Risk

In both military and corporate operations, one thing is drilled into every plan: assess and manage your risks. This isn’t a one-time step; it should be a thread running through all the steps. I’m listing it here explicitly because in data projects, risk management usually gets overlooked until something breaks.

As you plan and execute, keep asking: “What could go wrong, and what are we doing about it?” Here are some common risk areas in data projects and how to tackle them:

• Data Security Risks: There’s always a threat of breaches or leaks. Implement a solid cybersecurity framework from day one. That might include access controls, encryption, backups, and compliance with regulations. Don’t wait for a Target-style breach to bolster your defenses.

• Privacy and Compliance Risks: Know the rules that apply to your data and ensure your plan doesn’t inadvertently break them. If one COA involved uploading data to a cloud service, did you check if that’s allowed for personal data? Better to find out now than from a lawyer later.

• Project Execution Risks: Identify where your plan might falter. Tight timeline? Add a buffer or sprint to test critical components early. New technology? Plan a prototype or training to mitigate the learning curve. Key dependency on one person or vendor? Line up alternatives or cross-train team members. Basically, you want to have a Plan B for key risk points.

• Stakeholder Risks: What if a key supporter leaves the company or a department doesn’t cooperate with data sharing? It happens. Keep leadership in the loop and maintain relationships. Sometimes risk mitigation is as simple as regular communication and setting expectations, so no one feels blindsided.

In military ops, there’s a saying: “no plan survives first contact.” But a good plan anticipates failure points. By proactively managing risks, you’re acknowledging Murphy’s Law and preparing for it. Integrate risk thinking into every step. When gathering data, note quality issues; when developing COAs, consider worst-case scenarios for each; when implementing, do small tests or pilot programs to surface issues early. By treating risk management as non-negotiable, you won’t eliminate surprises, but you’ll reduce their frequency and impact.

One more tip: document your major risks and mitigations. This can be a simple risk register or even a bulleted list in your project plan. List the risk, likelihood/impact, and what you’re doing about it. Review it periodically with your team. It keeps everyone alert and ready to respond if a risk starts turning into reality.

Step 6: Implement the Solution

You’ve got an approved plan and a handle on the risks. Now it’s time to execute. In Army terms, this is where you transition to troop leading procedures (TLPs) and actually carry out the mission. In corporate terms, it’s implementation: getting the solution built, tested, and rolled out. This is where project management kicks into high gear with Gantt charts or Scrum boards. The MDMP mindset, however, still offers some guidance for smooth execution:

• Consider a pilot or phased rollout. It’s like a live-fire exercise before the big mission. In the military, you often don’t get to “test” an operation in advance. But in business you can! If possible, do a pilot program or a soft launch. User acceptance testing (UAT) can help you avoid critical mistakes early on. Ideally, implement the new data process in one department first, or release the analytics tool to a small user group. This lets you catch any issues in a controlled setting and refine before full deployment.

• Choose your execution approach (waterfall vs. agile). MDMP might feel very sequential (do steps 1–7 in order), but execution can be agile. You can iterate on the solution as you develop it. Perhaps you’ll use Scrum sprints to build pieces of a data pipeline, adjusting as you get feedback. Or maybe a traditional waterfall approach makes sense if it’s a short, well-defined project (though those are rare). Sometimes you need rapid maneuvers (agile), other times a well-planned siege (waterfall). Reference The Future of Project Management and choose a “way of working” that fits your project size, team, and culture.

• Assign clear roles and responsibilities. Everyone on the team should know their tasks and who’s in charge of what. In an operation, every squad member has an assigned duty; the same goes here. Clarity avoids things falling through the cracks. Make sure the data engineers, analysts, IT ops folks, etc., coordinate like joint forces. As the PM, you have to make sure it all syncs up.

• Keep communications tight. During execution, hold regular meetings (stand-ups, weekly reviews, whatever fits) to track progress and issues. Maintain that situational awareness you honed in planning. Encourage the team to flag problems early; transparency is your friend.

• Drive user adoption. The project is worthless if no one ends up using the product. Even the best system will fall flat if users do not understand it, trust it, or know how it fits into their workflow. Test with real users, deliver focused training, communicate clearly, and assign ownership.

• Be ready to adjust on the fly. No matter how great the plan, reality will throw curveballs. Perhaps a data source you planned on becomes unavailable, or a stakeholder changes their mind about a requirement. Channel your inner platoon leader: adapt, improvise, and overcome. Because you did steps 1-5 and you understand the intent and priorities, you can make informed adjustments without derailing the mission.

Implementing is where the rubber meets the road, and also where many projects bog down. But with your structured plan and risk mitigations, you’re in far better shape than the average PM. Keep leadership informed as you hit milestones - it keeps their confidence high that your “military approach” is working.

One caution: avoid the “launch it and forget it” trap. A project doesn’t end at go-live (which leads us to our final step…). But during implementation, it’s easy to develop tunnel vision on just getting to that finish line. Push yourself and the team to maintain quality and discipline through the finish. Remember, amateurs talk strategy; professionals talk logistics. Execution is all about the follow-through, and this is where your attention to detail will pay dividends.

Step 7: Supervise and Refine

Mission accomplished? Not so fast. In the Army, after any operation, we’d conduct an After-Action Review (AAR) and continuously monitor the situation. In business, too often we declare victory the moment a project is delivered and then immediately move on to the next fire drill. Step 7 is meant to remind you to follow through and make it stick.

Supervising in this context means keeping an eye on the solution after implementation and ensuring it’s working as intended. Refining means making adjustments and improvements based on real-world feedback. Here’s how you can carry this out:

• Monitor the outcomes. Remember those success criteria you identified back in Step 1 (the end state)? Track them. If the goal was to improve data quality by X%, or reduce report turnaround time from days to hours, measure it. Set up dashboards or periodic checks on key metrics. You can’t manage what you don’t measure.

• Get user feedback. Talk to the people using the new data system or affected by the new process. Is it helping them? Any pain points? Often the true test of a data project is whether it’s actually being adopted. If half the staff are bypassing the shiny new tool you built, that’s something to address (maybe they need more training, or maybe the tool needs tweaking).

• Conduct a post-project review with the team. What went well, what didn’t, and what did we learn? This is your AAR. Some call it a project retrospective or post-mortem review. Be blunt in assessing things. This isn’t the time to place blame, but rather to learn and improve. If the data integration launched two months late, figure out why and write down lessons learned for next time.

• Iterate if needed. Use feedback to refine the solution. Perhaps you discover the automated data pipeline fails on edge cases – schedule a mini-project to patch that. Or users want additional features on the dashboard – groom those for a future phase. Tweak and repeat.

• Ensure maintenance and ownership. One danger after project completion is that no one is clearly responsible for the ongoing success of whatever you built. Assign (or help the organization assign) an owner for the new data process or system. It could be a department head, a product owner, or maybe you transition it to an operations team. Just make sure it doesn’t fall into a black hole.

This step often gets neglected because, by the time a product is delivered, everyone’s exhausted or already reassigned. Try to budget a little time and resources for this supervision phase up front. Even a brief period of hyper-care (say, 2-4 weeks post-launch support) can make a world of difference in catching issues and solidifying the value of your product.

And with that, you’ve effectively cycled through a full MDMP-like process for a data project. You’ve managed what many in the corporate world never do: bringing structure, discipline, and adaptability to an arena that desperately needs it.

MDMP Cheat Sheet for Data Projects

By repurposing the Military Decision-Making Process, we introduced structure and clear thinking into the wild world of data project management. Let’s recap our battle plan:

1. Identify the Problem/Opportunity. Avoid ambiguity; nail down what you’re solving and why it matters.

2. Recon the Data. Know your environment and assets. Align stakeholders on one reality.

3. Develop Courses of Action. Don’t charge up the hill without considering different angles of attack.

4. Evaluate options and decide. Weigh the risks, costs, and benefits, then get the boss’s buy-in on a clear course.

5. Manage risk. Anticipate the pitfalls and armor up accordingly.

6. Implement the Solution. Lead the implementation, adapt to surprises, and keep the team coordinated.

7. Supervise and refine. Secure the win by monitoring results and continuously improving. Never skip the debrief.

If you’re a project manager (especially one with a military background), you already have the tools to cut through corporate nonsense. You just need to apply them. The next time you’re handed a data project that seems like a hot mess, take a deep breath and channel your inner staff officer.

Your call to action: Try using this MDMP-inspired approach on your next project, even if it’s a small one. You’ll likely find that decision-making is more straightforward, risks come into focus earlier, and your team moves with a greater sense of purpose. You might even impress a few colleagues with your “military grade” organizational skills.

Drop your biggest data battle story in the comments. Bonus points if it involves SharePoint.