This article won’t contain any hot T-SQL code or cool execution plans. In fact, the project management tools and advice it contains will not improve your coolness factor at all, although perhaps your choice to become a DBA sealed your fate, in that regard.

Deep in your heart, though, you know that your job as a Database Administrator comes with a lot more responsibility than just speeding up queries and fixing broken servers. Managers expect database administrators to be shape-shifters. We need crazy-deep knowledge of the technology (did you know that SQL Server 7.0’s favorite color is black?), communication skills like one of those people on TV with the talking and the podium and stuff (I didn’t say I had these skills), and the organizational skills of a retired drill sergeant with OCD.

For DBAs, project management skills, of which organization and communication form a core part, are both our weapon and our shield. With them, we can fight off the causes of long hours and stress, defend against the subjective politics of our employers, and protect our right to do high quality work. Learn them and you need never feel overworked and undervalued again.

A DBA’s Crazy Workload

Most people imagine that DBAs typically spend the majority of their time sitting in a dusty cubicle that smells of stale coffee and heated electronics, tapping away at some impenetrable PowerShell script or intricate ETL (Extract-Transform-Load) task. Indeed, they do, for it is the DBA’s job to organize, code, schedule and execute a wide variety of administrative tasks. These tasks alone require considerable time-management and organizational skills, as well as quite a bit of sitting in a cubicle in front of a monitor.

However, in addition to these everyday tasks, many DBAs, especially more senior ones, will have multiple other projects going on that they have to schedule and track, and for which they are expected to provide updates. For example:

• Unplanned support work
  “Hey – hypothetical question. If I ran an altertable statement on the Customer table in production rather than in development, that’s cool, right? Oh, and I just heard from a customer that the system is down. Can you look into these two totally unrelated things?”
• Consulting on development projects
  “Hey, can you help me debug this cursor inside a trigger that I wrote to update my Twitter feed?”
• Maintenance projects
  “Why does your status report always include the item Make Peace Offering to the Replication God?”
• Long-term build-outs
  “Remember when I should have asked you to build a new production server a month ago? Is that done yet?”

A DBA’s Place in the Organization

Organizational skills matter more to a DBA than many other technical jobs, due to the diverse nature of their workload. In addition, the diversity of the workload exposes the DBA to a greater surface area of the organization than is typical for most technical roles. As part of our jobs, we talk to many people:

• Vendor’s technical resources – mainly to ask why they need “sa” access, but also to request updated pictures of them that are coincidentally the size of a dartboard.
• Internal development resources – mainly to ask politely why they decided that a homegrown triple-nested cursor implementation of GROUPBY was a good idea, but also to enquire, for no particular reason at all, about their food allergies.
• Business stakeholders – mainly to discuss capacity-planning decisions, but also to find out how to prevent an in-ear Bluetooth headset from affecting one’s golf swing.
• Internal semi-technical resources (project managers, product managers, business analysts) – mainly to help with decisions about performance, capacity, and future goals for each product that needs database resources, but also to spread misinformation (“What, you didn’t know that using the first column in Excel has been outlawed as part of the Patriot Act?”).
• Internal IT resources – mainly to work with them in configuring and securing the hardware and software platforms on which the DBMS infrastructure depends, but also to trade Magic: The Gathering playing cards.
• Management resources – to complain about all the above people.

Since we talk to so many people, we are at higher risk of finding ourselves in the crosshairs of the blame gun.

The Dark Side of Being a DBA

High risk of exposure to the deadly rays of the blame gun is the primary disadvantage of being a DBA. A blame gun is a device used by the above-referenced people if projects go awry, or you get in the way of their reputational momentum. Even if you’re essentially innocent, the blame gun can harm your reputation, career progression, and salary. There is no waiting period for its use and typically the sniper fires from long range.

In my experience, these specific situations, in particular, draw a DBA into the laser sights of the blame gun:

• A project timeline changes and your tasks suddenly overlap with another project
  “Well, our project shifted back two weeks and so your part of this project now overlaps with your part of the other project and I miss the part where this is my problem.”
• Unplanned work overwhelms your working time and leaves you unable to execute on any planned projects
  “He didn’t have the development database server ready in time, which is funny, because the word database is in his title.”
• You perform maintenance work, even planned maintenance work
  “I couldn’t care less about Windows updates that you applied last night; I want to know about this security hole I heard about this morning.”
• People “misunderstand” your day-to-day responsibilities
  “Dave? Oh, he’s in charge of making sure we don’t use the first column in our public Excel documents.”

The more DBAs are exposed to the rays of the blame gun, over time, the more jaded they become, until the unending trail of half-truths and perceived failures turns their beards into Brillo pads of fear and hatred.

OK, I’m being both flippant and melodramatic. The serious, underlying point is that many DBAs are very bad at managing their time, managing expectations, and “advertising” to the organization exactly what it is they do. However, you can handle your numerous and diverse projects and you can avoid the blame gun, just by applying some simple project management techniques.

The Shield of Project Management

What is project management?Expressed as simply as possible, it is the organization of “things” to get “stuff” done. Normally, we call the things “resources,” which is a fancy term for sufficiently employable hominids, which some feel is an advanced term for about 80% of their coworkers.

The non-technical members of your organization expect everyone to know about how to manage a project. Good news: we are all project managers. Each time you plan your Saturday you are planning a (probably very lame) project. Every project comprises the following common sense bits of information:

• What are we doing? (project summary)
• Why are we doing this? (project charter)
• Who is doing what? (resource assignment)
• How could it go sideways and fail? (risk plan)
• What is the plan? (project plan baseline)
• How is it going? (project plan)

For every task that takes more than a few hours, you should be prepared to communicate the plan to your manager in the appropriate form. For smaller projects, this may take the form of simple answers to the Who/What/When/Why questions, as illustrated here for an index maintenance task:

• Why? Maintaining indexes makes everything faster and brings great honor to our company.
• When? We perform the maintenance outside peak hours of usage.
• Who is doing it? An automated job, and the Database Team is responsible for making sure it runs.
• How could it fail? It could fail to run, or run for too long. It could run and fail and not be noticed.
• What is the plan? Every 3rd Tuesday.
• How is it going? It’s been running cleanly for one week. We made one change to speed it up.
• What changes to the original plan have occurred? We changed it so that we have a process to re-evaluate what it does as we add databases and new systems to each machine. The notification system works like this…

As DBAs, we need to learn how to communicate our plans in the correct terms, depending on to whom we’re reporting. A manager does not want to hear a winding tale of how there was no 64-bit driver, and the ensuing search for suitable third-party components. They just want to hear about how it affects the plan (“We burned through 40 hours due to Risk #3, which we couldn’t mitigate.“).

For larger projects, we need to create proper documentation. The following sections describe what sorts of documentation are justified in these cases.

Common project management terms cheat sheet

When you communicate your plan, you need to use a commonly understood language.

Project charter

The project charter is a document that explains why you’re doing the project. If you have to reread this after every meeting to understand what is going on, then you are officially on a massive corporate project. For the project of getting my family out the door to go to the zoo on a Saturday, our simple example, my project charter might look something like this:

We will visit the local zoo and strive to have a safe, fun day in the eyes of our children. We will teach them about animals. We hope not spend more than $500 on food, drink, and gas.

Work Breakdown Structure (WBS)

A WBS is just a list of all the work the team needs to complete for a project, broken out into appropriate milestones, and with some care taken to list dependencies and parallelize the tasks. Be aware of who is able to complete the tasks for each milestone.

Figure 1: The Work Breakdown Structure for the Zoo project.

Such a document can assist in further planning and assignment of tasks, and make it easier for us to adjust the plan if people are out sick.

Critical path / long pole

The “critical path” comprises all the elements that, if you forget any one of them, will put the project’s success at risk.

Similar to critical path, the “long pole” refers to the task, or set of tasks which, even after optimization, will take the longest. Ultimately, the long pole defines the minimum amount of time that the project will take; speeding up anything else will not speed up the overall timeline.

For the Zoo project, the long pole is preparing kids #3 and #4 for transport. This milestone, until complete, fully occupies both parents. Everyone else might be ready to go before this happens, but we can’t leave until it does.

Resource allocation

This is project management speak for “who is doing what.” As the project grows larger, so the terms employed increase in number and complexity. On a two-person project, we assign tasks; on a sixteen-person project, we allocate resources; on a seventy-six-person project, we allocate resources according to the Resource Allocation Matrix Committee Procedure Strategy Giraffe Hat Check-list (OK, I made up the bit about giraffe hats).

The constraint triangle

a.k.a. “The three-sided triangle,” a.k.a. “The triangle of project management”

A project has a schedule, a scope, and allocated resources, and a change to one affects the others. Remove a person and it takes longer to complete the same amount of work; if you don’t care about quality then you can get done faster; do less (reduce the scope) and you finish early.

It is amazing how often people reference this triangle, often as a defense mechanism against the insanities of requests for large changes in scope without any adjustments to the schedule.

Burndown rate

How quickly you spend the money allocated to a project. An hour into our Zoo project we are all holding large drinks, for which budget was allocated. The large stuffed panda that the 4-year-old is holding was an unforeseen expense.

Checking-in

A term used for the act of a project manager creeping up behind you, during the 30 seconds in which you check your personal email, to see why your task on the critical path is not yet complete. Also called “touching base” and “sync-ing up.”

At risk

If a task or project is “at risk,” it doesn’t mean it grew up in a bad neighborhood: it means it will probably be late.

Specific defensive moves

Armed with some common project management terms, you can now defend yourself from attacks and, over the coming sections, I’ll explain how.

Outsource prioritization for items assigned to you

Department A and Department B don’t like each other and both have work for you to do. According to the manager of each department, their project is as important to society as the smallpox vaccine, and he or she demands that you work on it until the project is finished and/or you collapse from exhaustion.

Each time you receive a work request, note down a brief description, the name of the stakeholder, the request date, and the priority in terms of expected completion date (at least according to the stakeholder).

Department A’s task might look like this:

• Title: Create a database server for Department A for the tracking of Department B’s birthday cake consumption.
• Stakeholder: Department A’s assistant manager (a.k.a. Sudden Def).
• Priority: Should be complete before the next time that you blink or you will be fired in a humiliating way.
• Date reported:3/20/2012 3:02 PM EST.

When Department B’s manager swings by, calmly write down the next task:

• Title: Create a database trigger on Department A’s vendor tracking database that removes every odd invoice record from its database.
• Stakeholder: Department B Assistant Manager (a.k.a. Your Median Nightmare).
• Priority: Should be complete before I get back to my desk or I’ll send you an angry email, and then request status updates every 15 minutes until I fill your Inbox quota.
• Date reported: 3/20/2012 3:12 PM EST.

What do you work on next? What side do you take? The fact that you have friends in Department A shouldn’t really affect which project you work on first thing the next morning.

In fact, you cannot make this call. You are here to work on the technical execution, not on sorting tasks based on business priority. Without a clearly established priority, we tend to sort by degree of interest, level of difficulty, or what we can describe best as “DBA order.”

None of these is easy to explain to a non-technical person in a heated political situation. You need to stay away from these potential political fights. In all cases, you should outsource the prioritization of your work to your boss, and establish this as an understood process. If you work at a small company, where there is no one who can break these ties in your organization chart, then you simply put the two stakeholders in contact and ask them to arm-wrestle to decide which is the most important. You cannot make an arbitrary call so do not begin work until someone makes a decision.

Never say “No,” just communicate that everything has a cost

One tip you pick up from consulting (more useful but equally important as being able to hold an intelligent conversation after three drinks) is the idea that you “Never say No.” Does this mean you wind up abused and over-committed, based on the priorities of others? Absolutely, yes… wait, I mean, no! It means that you learn to communicate that every task has an associated cost. This forces the project owner to take more responsibility and think more deeply about hard prioritization tasks.

Let’s walk through an example:

Dale: Hey, Dave. I don’t think I ever got a chance to thank you for standardizing us on SQL Server after years of a mix of Access, complex systems in Excel, and various versions of custom vendor databases. However, times change and it feels like we need to start moving with the NOSQL flow. I’ve read several white papers on MongoDB, and talked to a guy with a double nose-ring at Borders, and I’m pretty excited. It’s free, fast and elegant. I think it will revolutionize our inventory systems. I need you to sunset SQL Server on these systems, and move to MongoDB immediately across all projects.

Dave: It’s a terrible idea on so many levels. Let’s fight to the death.

Bad answer; try again.

Dave: OK, cool, that sounds like an exciting move, but let’s do some quick pre-planning to decide the best first step.

Moving to MongoDB is a big shift; that’s OK but, by my estimate, eight members of staff will require additional training. Let’s estimate that each hour a member of the team is not working but instead taking the training hour, as costing us $150/hour. If we assume that two of them will need in-depth training, and the rest need an overview of about a week, then the first two can provide additional internal training for the others. That’s four weeks for the pair, plus an additional month tapered out over the next few months, which gives us a total of (Dave types in Excel like a twitching hamster) $32,000 for the primary training and $24,000 for the secondary training. Of course, we ought to include a cost estimate for delays to existing scheduled projects during the ramp-up period, let’s say $12,000. That gives us a total cost for training and ramp-up, which we will call Milestone 1, of $68,000.

Next, we’d need to enumerate the in-progress projects and the existing systems and decide which ones will be the first to move from SQL Server to MongoDB. We have four projects in progress, one of which is quite large and 80% complete, and 16 existing systems…

Good answer.

Dale: You know what? This has given me a lot of new good information. Let me go back and think about this.

Communicate risk without being obstructive

Every DBA has sat in a meeting, rolled their eyes and thought “Girl, this is a straight-up nasty mess!” Some DBAs open their mouths right after thinking this and say rash things that get them branded as Negative, Not a Team Player, Too Intense, and Distracting. It’s all just ammunition for the blame gun. Identify the risks; think a little harder about risk mitigation.

• Risk: the thing that is going to make this blow up in your face.
• Risk mitigation: the thing that is going to prevent it from being quite so bad.

Feel free to express your concerns, but only if you have a productive solution. Some examples (with the productive part in italics):

• This is new technology and I know that everyone is excited about it, as am I. However, we have a lot to learn and I’d hate us to stumble right from the start. It would undermine people’s faith in the technology, and possibly prevent us from exploiting it more fully later. I think we’d be wise to invest some more money on education and prototyping as part of the initial project plan.
• It seems like nobody knows what is going on with this project, which is understandable, considering how thinly spread the time of the projectleaders is, with all the other projects going on. Would it make sense to shift priorities a bit so that one or two of them can focus more on this project?
• I agree that moving datacenters is a great idea and that x64 is better than x32 by some unknown mathematical factor, but changing so many systems at once might fail. I think we should instead identify a system that can transition easily and begin the process with that one. After this, we will have some momentum and learn some valuable lessons to tackle the rest of them. I’m nicknaming this Small Bang and am trademarking it, OK?

Pay attention to conflicting schedules

One persistent problem makes project planning for a DBA difficult: on an installation or build-out project, the vast majority of the database-related tasks occur at the very beginning and end of a project timeline. At project kick-off, everyone is wide-eyed with enthusiasm and desperately keen to get started, and they need the DBA to set up the required database environment, quickly. They then go off for several months and do unspeakable things to it, and finally come back at “crunch time” begging you to push it to production.

It is during this final stage that the development staff or vendor support people are looking for someone else to take over blame for the project being late, while they wrap up the last 10% of their work (which in some cases is actually 80%).

In order to avoid a blast from the blame gun, it’s vital that a DBA avoids scheduling conflicts that involve two projects entering “crunch time” simultaneously. Given that project timelines tend to be about as stable as Jell-O on a treadmill on an airplane, this is easier to say than to do.

However, DBAs must always track potentially conflicting timelines, and throw up a flare as soon as they smell any trouble, as project plans shift.

Make a project plan for recurring, unappreciated tasks

When off-hours maintenance tasks, such as SQL Server upgrades, improving the disaster recovery process, keeping the backups running and so on, run smoothly, they tend to become “invisible” to the DBA’s boss.

However, things don’t always run smoothly. Consider a simple database procedure that you have to perform weekly, off-hours, and that takes forty-five minutes, in the normal case. At the end of each quarter, that same task might take two hours. In addition, if the development team failed to do the MIQDUT (Most Important Quarterly Data Update Task) on time, you have to perform the steps out of order, in which case it can take up to six hours.

If you hide this complexity from others, including your boss, then you’re unlikely to get due credit and appreciation for what might be hours of important and exhausting work. Of course, when things go awry, either due to circumstances beyond your control or because you made a mistake, then suddenly everyone knows about it.

Here are two things you can do to avoid this situation. Firstly, for each task, create a comprehensive check-list of every required step, so that you avoid the sort of simple mistake and subsequent disruption that brings shame to you and your family in a dramatic and highly visible fashion. It is very easy to forget steps as you perform, check, or monitor simple changes, and this is why a simple check-list can be a lifesaver.

I like to ride bicycles and I have a simple check-list of items that I need to remember to take, built from years of mistakes, like forgetting to wear a helmet, or not having cash to bribe a border patrol guard (sometimes I get lost). The list contains cash, ID card, ID on wrist, mobile phone, helmet, 400 calories of food, 16 oz. of water, 2 spare tires, a light, and a knife. I refer to this list, and ensure I have all these items, every time I take a bike ride, even if it is just to ride around the local neighborhood.

Are you doing a manual fix to a log-shipping or replication job? Did you remember to turn the monitoring alarm back on afterwards? A check-list can help you avoid these types of public mistakes, which cause massive delays the next day and expose you to a blame gun firing squad.

Secondly, use each check-list to create a project plan for these off-hours tasks, which makes it clear when these tasks occur and how long they take, so your boss and others fully appreciate the work you do. You can also use this project history to predict future work more accurately.

Figure 2 shows a typical check-list for an “Apply Patches” maintenance task. It exposes the preparation and clean-up tasks that accompany the actual execution, and will give your boss or other stakeholders a proper appreciation of the work involved and how long it takes.

Figure 2: A typical maintenance checklist.

Offensive project management

Up to now, we’ve discussed ways in which DBAs can use project management techniques to protect themselves from the rays of unwarranted blame. However, project management skills are also an offensive weapon. We can use them to make sure that people make the right decisions, that projects start in the right way, with the required resources, and that we avoid altogether certain types of future maintenance work. Ultimately, good project management skills provide you leverage to advance your career. The following sections describe some specific project management “moves” that can help.

Remove technical debt

All experienced DBAs learn to fear technical debt, i.e. any short-term solution to a problem that they know will create, rather than eliminate, future work.

A good example of a technical debt is the patched-up network infrastructure that really doesn’t do what you want it to, slows down your backups, and causes occasional failures, which lead you to wake up and fix them about once a month. So how do you convince your boss to spring for that new router and a second NIC on your database server? Many DBAs resort to emotional complaints, such as “Man, that is a pain!” or “I missed watching the American Idol finale last night because the backups failed!”

Unfortunately, your boss doesn’t care. However, every time it fails, that flaky network infrastructure is costing your organization money. You need to calculate that amount and communicate it, repeatedly. When you tell your boss, repeatedly, that the network issues are costing the company $13K a year, or $4K every time they cause a failure, then eventually the part of their brain that does mathematics will stage a non-violent sit-in until the hand starts writing checks.

Calculating the cost of an ongoing problem is a complex problem but even a rough estimate can clarify thinking. For a simple down-time event, consider the following costs:

• Resource time – how long it takes you and others to deal with the issue. Estimate resource time based on simple aggregates such as $100/hour. Remember that while some people are fixing the problem, others are communicating the problem to clients; include all their time in your estimates.
• Shifts in schedule – every time you work to resolve down-time you delay planned work, in a domino effect. Even spending 10-20% of your time on unplanned work can have a big impact on the confidence level you and the organization can place on any future project planning.
• Business loss – down-time of internal or external systems means money lost, directly or indirectly, by the business. For external systems, you can estimate the loss based on transactional volumes; for internal systems, estimate based on the time wasted by those that depend on them. For any type of system, keep in mind the reputational cost of a system that your customers or employees can’t trust to be available.
• Cultural costs – if your organization spends all its time fighting fires then, eventually, only firefighters will be successful and not those that can resolve or prevent the types of problems you are experiencing.

Justify hiring

Are you overworked? How do you prove this? Go to sleep during meetings and send 3 a.m. emails? Dye your hair red and insist people call you “Cranberry Dan the No Sleep Man”? Show your boss your DVR list, with 87 hours of unwatched television?

Again, these responses are too emotional and not likely to have the desired effect, which is to convince your boss to hire someone to help. Put another way, you have to help your boss justify hiring someone to help you, and the correct way to do this is with data.

When you decide you need a hand, you have to build a proper business case to support your cause. Following are the sort of metrics you need to track and report:

• The amount of time you spend on unplanned work.
• The long-term fixes you can’t do because you don’t have enough time.
• Projects started but now “shelved” due to inadequate resources.
• Projects never started due to lack of resources.
• Projects hamstrung with technical debt and riddled with Band Aids.
• Tasks that are falling through the cracks because nobody is there to catch them (proceed with caution here). Are you planning for future growth, up to date on new security best practices, or fully familiar with new technology that could help your company solve its challenges?

Prove your performance

Most people regard their performance review as a sort of colonoscopy for the mind; unpleasant, necessary, Advil needed immediately afterwards, and more likely to produce confusing or bad news than the reverse. You shouldn’t think of it this way, and not only because it is a bad metaphor. You should think of it as a way to prove to your boss how awesome you are, and to show off and reflect on all your amazing feats of the past year.

What can you show them? Well, dear reader, you can show them the project plans for all the projects you completed, your task lists for maintenance work, your analysis of what Band Aids cost the company, and possible solutions, if only resources were available. Since you have also tracked costs carefully, you might even be able to roll up the costs and say things like “I saved the company $200,000 this quarter” with a straight face:

• License cost savings by the consolidation project that moved SQL Server into virtual machines: $87,000.
• Reduction of down-time events by implementing a failover solution for production (reduced average down-time from 2 hours to 10 minutes a month): $105,000.
• Increased productivity by switching the decaf in the break room to Starbucks Extra Addict laced with Red Bull: $8,000.

Ultimately, you need to treat performance reviews as another case where your boss really wants to do something (give you a raise), but needs proof first.

Onwards

It is very easy for highly-skilled technical people, with years of experience in a competitive market, to rest on their technical skills to prove their value. However, equally important is the ability to speak the language of the business, track work and costs, and stay out of trouble.

I presented, with a degree of levity, my project management techniques. However, they really can protect you from overwork and under-appreciation, and they can help further your career and build for you a better future.

At some point in your DBA career, you will face the same decision as many other technical roles: should I move into Management or stay Technical? Most organizations will try to support you with either choice. However, only if you have mastered project management will you have any chance of moving into a role where you are making things happen with your team rather than your fingers. Using the techniques discussed in this article, tracking the cost, risk, and politics of each task that you do, you will be able to explore either option.

This was originally published as a chapter from the book ‘Tribal SQL’ which is a reflection of how a DBA’s core and long-standing responsibilities sit alongside new thinking and fresh ideas about where the DBA role is going, and what it means to be a DBA in today’s businesses.

Currently available on Amazon, in paperback and Kindle versions – all royalties go to Computers 4 Africa.