Consulting – Data Savvy

There are multiple ways organizations can engage with a data (DBA/analytics/data architect/ML/etc.) consultant. The type of engagement you choose affects the pace and deliverables of the project, and the response times and availability of the consultant.

Two women are seated at a desk looking at a laptop screen. One woman is pointing at an object on the screen while the other looks on. — Photo from Unsplash

What types of consulting engagements are common?

Consulting engagements can range from a few hours a week to several months of full-time work. The way they are structured and billed affects how consultants work with clients. Here are some types of engagements that you will commonly see in data and IT consulting. .

Office hours/as-needed advising: This engagement type usually involves advising rather than hands-on work. This type of engagement may be used to “try out” a consultant to determine if they have the required knowledge and how the client likes working with them. Or it may be “after-care” once a project has been completed, so a client has access to advice on how to keep a new solution up and running. In this type of engagement, a consultant’s time is either booked in a recurring meeting or as needed.

Time & materials/bucket of hours: In a time and materials (T&M) engagement, a client has purchased a certain number of hours with a consultant that may be used for advising or hands-on work. (The “materials” part is for other purchases necessary such as travel or equipment.) While the client may identify some deliverables or outcomes to work towards, they are paying for an amount of time rather than a specific deliverable or outcome. This bucket of hours is often useful for project after-care where the consultant will be hands-on. It is also useful for a collection of small tasks that a client needs a consultant to complete. Clients commonly use these hours over several partial days or weeks rather than engaging the consultant full-time.

Retainer: When clients engage consultants on a retainer basis, they are paying for them to be available for a certain number of hours per week/month/quarter. This is commonly used for recurring maintenance work. It can also be used when a client knows they will have enough development tasks to engage the consultant each month, but they don’t know exactly what those tasks will be. This type of engagement is usually a 3- to 12-month commitment.

Project-based time & materials: In this engagement type, there is a specific project a client needs a consultant to complete or assist in completing. There is a scope defined at the beginning of the project with some rough requirements and an estimated timeline. If the work takes less time than anticipated, the client only pays for the hours used. If the work takes more time (usually due to unforeseen issues or changing requirements), the client and consultant will have to agree to an extension.

Project-based fixed-fee: In a fixed-fee project, the client and the consultant are agreeing to an amount of money in return for specified deliverables. This involves much more up-front effort in requirements gathering and project estimation than a time & materials engagement. This is because the fee stays the same whether the consultant finishes in the estimated time or not. If the fixed-fee project costs $100,000 and it ends up using $105,000 worth of consulting time & materials, the client does not owe the consultant $5000 (unless they have violated a part of the agreement and agreed to the additional hours before they were worked). In this case, the consultant simply makes less profit.

Staff augmentation: In a staff aug agreement, the consultant and client agree that the consultant will work a set number of hours, usually close to full-time, per week in a specified position. There are no stated deliverables, just expectations of hours worked and skills to be used.

Risks and rewards

Office hours

Office hours is the lowest level of commitment for both clients and consultants as it usually involves a small number of hours. As a client, you aren’t stuck for long if you find the consultant isn’t a good fit.

But if you don’t agree to recurring meetings, you are taking a chance that the consultant will not be available on the day and time you need them. You must understand that the consultant has other clients, many of whom are paying more money for more time with the consultant, who is “squeezing you in” between tasks for other clients. I personally enjoy these types of engagements because they are easy to fit in my schedule and don’t usually require a lot of preparation before meetings.

An office-hours engagement is not appropriate for complex hands-on work. It can be good for design and architecture discussions, or for help solving a specific problem. I’ve had clients successfully use office hours for help with DAX measures in Power BI. I’ve had helpful white-boarding sessions during office hours. But when something looks like it will become a full project, or there are urgent troubleshooting needs with high complexity, I usually suggest that a different type of engagement would be more helpful.

Bucket of hours

The biggest risk with the bucket of hours is scheduling and availability. It can be helpful to agree that the hours must be used by a specific date. This helps the consultant plan for those hours in their schedule and ensure that revenue will be earned in the period expected, rather than leaving the agreement open indefinitely. But clients must manage the hours to ensure they are used before the expiration date.

This type of engagement is best when there is effective communication between the client and consultant and deadlines are somewhat flexible. Since the consultant isn’t engaged full-time, they will have other deadlines for other clients that they must work around. This sometimes requires a bit of patience from clients. Unless it is specified in the agreement, clients usually can’t expect consultants to be immediately available.

I’ve seen two ways this type of engagement is used successfully.

Clients clearly communicate tasks and deadlines each week and consultants deliver them at the end of the week, until the engagement is over.
Clients use the hours for non-urgent support, where work consists mostly of paired programming or troubleshooting a system with which the consultant is familiar. Clients give the consultant at least a day’s notice when scheduling a meeting. The consultant only has tasks that arise as action items from the programming/troubleshooting work sessions.

While there may be a theme to the work, no one has agreed to deliver specific outcomes in this type of engagement. If that is needed, a project-based engagement may be more suitable. Buckets of hours are good for short-term tasks and support.

Retainer

Retainers involve a bit more commitment, as they usually last for multiple months. Often, retainer hours are discounted compared to time & material hours because the stability and long-term relationship are valued by the consultant.

At DCAC, we often use retainers for “DBA-as-a-service” engagements, where clients need someone to perform patching and maintenance, monitor databases, tune queries, and perform backups and restores. They don’t know exactly how many hours each task will require each month, but they are sure they will need a consultant for the agreed upon number of hours.

Retainer hours are often “use them or lose them”. If clients don’t give the consultant work to do, the hours won’t roll over to the next month.

Because retainers usually involve part-time work, it’s important to set expectations about the consultant’s availability. If a client needs the consultant to be available immediately for urgent support matters, that should be written into the agreement (e.g., “The Consultant will respond to all support requests within one hour of receipt.”).

It’s more difficult to do retainer hours for development projects. If the consultant uses all the hours for the month before a project is completed, the client either needs to find more budget for the extra hours or wait until the next month to resume project tasks. If there are real project deadlines, waiting a week or more to reach the start of the next month is probably not feasible. If you need a consultant to focus work on a single project with tight deadlines, it’s better to have a project-based engagement.

If the consultant is assisting other project members, and it is certain that the retainer hours will be used each month, it is possible to have a retainer for development efforts. I have a client who has a retainer agreement right now that has me perform a variety of small tasks each month. Sometimes it’s Azure Data Factory development and support. Some months involve writing PowerShell for automation runbooks. Other months, I help them troubleshoot Power BI models and reports. We meet weekly to discuss the tasks and assistance needed and plan tasks to ensure that we use the allotted hours each month without going over. But this only works because my client trusts me and keeps the communication flowing.

Project-based time & materials

This is the most common type of engagement I see in business intelligence/analytics consulting. In this project type, the agreement specifies expected deliverables and estimated effort for high-level tasks. While detailed requirements might not be determined up front, it is important to specify assumptions along with the scope and deliverables. If something violates an assumption, it will likely affect the time and cost it will take to complete the project.

With any type of project-based work, it might be helpful to include a discovery phase at the beginning of the engagement to better understand project requirements, constraints, and risks. After the discovery phase, the project estimate and timelines can be updated to reflect any new information that was uncovered. While this won’t keep scope and requirements from changing mid-project, it helps people plan a bit more up front instead of “going in blind”.

As with the other time & materials engagements, clients only pay for the hours used. So, if the project was estimated to take 200 hours, but it is completed in 180 hours, the client pays for 180 hours.

Project-based time and materials engagements often have consultants working full-time on the project, but that is not always the case. It’s important to establish expectations. Clients and consultants should discuss and agree to deadlines and availability for meetings and working sessions.

Project-based fixed fee

Fixed fee projects are all about deliverables and outcomes. Because of this, they carry the most risk for consultants. They require the most detailed agreements as far as scope, constraints, and assumptions. It is particularly important to include this information in the agreement and have both parties acknowledge it. Then, if something changes, you can refer to the agreement when discussing scope/cost/timeline changes.

It’s important for clients to read and understand the scope and assumptions. While it may be a less technical executive that actually signs the agreement, a technical person who can competently review the scope and assumptions on behalf of the client should do so before the agreement is signed.

Because it is easy to underestimate the work needed to complete the deliverables, consultants often “pad” their estimate with more hours than what they think is necessary to cover any unexpected complications. Most people underestimate effort, so if the actual hours were to be different, this would usually end up in the client’s favor. But it’s not uncommon to see large amounts of hours in an estimate in order to cover the risk.

It’s important for the person estimating the project to consider time required for software installation and validating system access, project management, learning and implementing unfamiliar technologies, knowledge transfer, design reviews, and other tasks that don’t immediately come to mind when estimating. If there are less experienced people working on the project, that could increase the hours needed.

I have learned that it takes less time to complete a project if it’s mostly me and my team completing the work. If I have client team members working with me, I usually have to increase the hours required, simply because I don’t know their personalities and skills and I’m not used to working with them.

Due to the risk of underestimation, many consultants do not like to undertake large fixed fee projects. Sometimes it’s better to break up a larger fixed-fee project into smaller phases/projects to reduce the risk. This is especially true when a client and consultant have not previously worked together.

Staff Augmentation

I personally do not consider staff aug to be true consulting. Staff aug is basically becoming a non-FTE (full-time employee) team member. It is a valid way to be a DBA/BI/ML practitioner, and many consultants do some staff aug work at some point in their careers. But it doesn’t necessarily require the “consultant” in the relationship to be consultative, and they may or may not have more skills than those present on the client team. Some companies treat staff augmentation as just a “butt in a seat”. But it’s also possible to be a knowledgeable and consultative consultant who happens to be working with a client through a staff augmentation agreement.

For independent consultants, the risk for this type of engagement is that it is likely full-time or close to it, which makes it difficult to maintain business with other clients. Having only one main client can be risky if something goes wrong. For consulting firms, there is an opportunity cost in allocating a consultant full-time to a client, especially if the consultant has skills that other consultants do not have. Depending on the length of the agreement, there is a risk that the consultant will feel like their skills are stagnating or be unhappy until they can work with a different client. For clients, having temporary team members can decrease consistency and institutional knowledge as people are only around for a few months to a year.

Choose an engagement type that matches the work you need done

You are more likely to have a successful consulting engagement if you go into it knowing the common risks and rewards. Many problems I have seen in consulting have been due to poor communication or trying to do work that doesn’t fit the engagement type. Whether you are a consultant or a client, it’s important to speak up if you feel like an engagement is not going well. There is no way to fix it if you can’t have a conversation about it.

Whether you are the client or consultant, you can propose changes to agreements before they are signed. If you find something is missing or concerning, speak up about it so everyone feels good about the agreement that is being signed. Consulting engagements are more successful when clients and consultants can support each other rather than having an adversarial relationship.

Consulting, Microsoft Technologies, Personal

Why I tweet about work and personal topics from the same account

September 26, 2022September 26, 2022 Meagan Longoria

Over the last few years, I’ve had a few people ask me why I don’t create two Twitter accounts so I can separate work and personal things.

I choose to use one account because I am more than a content feed, and I want to encourage others to be their whole selves. I want to acknowledge that we don’t work in isolation from what’s going on in the greater world.

I love learning things from people on Twitter. I find a lot of quick tips and SQL and Power BI blog posts from Twitter. I love seeing all the interesting data visualizations shared on Twitter.

A wooden table with a phone and a cup of espresso. The phone is opening the Twitter mobile app, and you can see the twitter icon in the center of the screen. — I often start my mornings with caffeine and Twitter.

But I also love learning personal things about people. I love to see photos of your dogs and views while hiking. I like knowing that my friend Justin is really into wrenches. And my coworker Joey (who I followed on Twitter long before I worked with him) is really into cycling. And my friend Matt is into racing. I followed all these people before I met them in person. Many of my Twitter friends became “IRL” friends after we met at conferences.

I definitely lurked around the SQL community (Power BI didn’t exist yet) for a while before I ever worked up the courage to say anything to anyone. And I started out with mostly data/work-related tweets. But as time went on, I realized how much I appreciated when others shared personal info about themselves, that helped me get to know them better. And I became more comfortable sharing more about me. So now I’m sort of giving back, with both professional and personal information.

Note: I do this personal/professional crossover only on Twitter, because I have deemed that to be an appropriate audience for both. I don’t share many personal things on LinkedIn. And I don’t share professional things on Instagram or Facebook. That’s my personal preference.

Are there risks to this? Absolutely.

People might stop following me because they don’t care for the personal content. My political opinions or obsession with my dog might turn some people off. Someone might be offended by my tattoos or my occasional use of profanity (which I never direct at someone and use more to express frustration/excitement/surprise). Or they may tire of my frequent use of gifs.

I know that potential and current clients see what I tweet. And it can and does affect their opinion of me. But when you hire me as your consultant, you get my personality and personal experiences as well as my tech knowledge. So, I don’t see it as being so very different from meeting me in real life at a conference or at another social event.

So far, it’s been an overall positive experience of having IRL conversations with clients about something I tweeted that they found helpful or entertaining. I do make a point not to name specific clients or projects unless I have their permission to do so (sometimes there are legitimate exceptions). I respect client privacy and confidentiality online and in person.

Before I could get to this place, I had to be secure in myself and secure in my employment and professional network. I recognize that not everyone will like me. That is true in person and on Twitter. And that’s ok. If you want to unfollow me, I’m ok with that. If you want to engage in conversations only about work stuff, that’s great. Feel free to mute words to tune out the rest of my tweets (your best bets are “Colorado”, “Denver”, “dog”, “kayak”, and “hike”). If you want to talk only about dogs and nature and my adorable and efficient camper, that’s also fine.

If you dig deep enough, I’m sure you can find some tweet that wasn’t my best moment. I’m sure I’ve said something regrettable in the 14 years since I joined Twitter. But I’m going to extend myself a little grace and remember that I’m human. And I’ll accept feedback if you think something I’ve said was unkind or made you feel unwelcome.

There is also a risk that someone can use this personal info against me, for harassment or identity theft. That is a risk for anyone sharing anything personal online. For now, I have assessed the risks and the rewards, and I find the rewards to outweigh the risks. I may decide differently later.

Do I recommend this for you?

Here’s the thing: I don’t think there are absolutes when it comes to how people use social media. If it makes you happy and it’s not hurting anyone, it’s probably fine.

It’s important to me that we remember that the people who teach us Azure and SQL and Power BI are people with non-work interests and personal struggles and interesting life experiences. And their more personal content gives me ways to relate to them outside of technology. Sometimes I learn really useful things from them, like the right type of lubricant to fix a squeaky door. Sometimes I notice a current event in their life that I can use to start a conversation at a conference.

Basically, I choose to use Twitter in a more human way. It’s working pretty well for me so far. You can decide if you have the desire and ability to do that. When this way of interacting with people stops being rewarding for me, I’ll reassess and take a different approach.

Consulting, Data Visualization, Microsoft Technologies, Power BI

Stress Cases and Data Visualization

March 26, 2020September 24, 2020 Meagan Longoria

Times are stressful right now. There is an ongoing pandemic affecting people’s health and livelihoods. Schedules are messed up, kids are home. People who aren’t used to working remotely are fumbling through learning how to work from home. And then there are the normal stresses that aren’t taking a break just because there is a pandemic: arguments with family members, home repairs, student loan debt.

Woman with her head in her hands — Life is stressful right now. It’s ok to not be ok.

I recently read the book Design for Real Life by Eric Meyer and Sara Wachter-Boettcher. I discovered it because I read another book by Sara Wachter-Boettcher, Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech that encourages us to look at the technology around us and consider how it can and has negatively affected people. If you work in analytics or web design, I recommend both books. She approaches design more from the context of user interfaces and web apps, but there is a lot of applicability to data visualization.

What’s a Stress Case?

Design for Real Life encourages us to consider stress cases. The idea behind stress cases is to consider our users as full, complex, sometimes distracted, vulnerable, and stressed-out people. They aren’t just happy personas who always click the right buttons and share all of our knowledge and assumptions.

Certain use cases, often labeled as edge cases, often go unidentified or dismissed as too infrequent. User interface designers, including data visualization designers, need to train ourselves to seek out those stress cases and understand how our design choices affect people in those usage scenarios. This helps us to minimize harm done by our design. But also, as stated in the book,

When we make things for people at their worst, they’ll work that much better when people are at their best.
Design for Real Life

There is a toxic trend in tech that we developers make things for ourselves, valuing the developers and designers over the users. Designing for stress cases helps us change that trend. We need to value our users’ time, understand our biases as designers, and make features that match our users’ priorities. A very applicable part of this for data visualization is to consider all the contexts that usage scenarios might happen.

Stress Cases in Data Visualization

Whether you are designing a visualization to be embedded in an app, included in an online news article, or published in a corporate dashboard, you can design for stress cases.

Let’s think about a corporate HR report built in Power BI that shows a prediction of employee retention. HR and team managers may use this information to help them assign projects or give promotions and raises. This dashboard and the conversation around it may address information related to identity (race, gender, sexual orientation). The use of the dashboard may affect someone’s compensation and job satisfaction.

How can we design for stress cases here?

We should be asking if we have the right (appropriate and validated) data to accomplish our goals, not just using whatever we can get our hands on. We definitely need to consider laws against discrimination that might be applicable to how we use demographic data. We need to consider the cost or harm done if we allow users to see these predictions down to the individual employee rather than an aggregation. And we should always be asking what actions people are taking as a result of using our dashboard. Have we considered any unintended consequences?

We want to use plain, easy to understand language. We want to explain our data sources and (at least high-level) how the predictive algorithm works. And we need to explain how we intend for this dashboard to be used. Basically, we want to be as transparent and easy to understand as possible. This dashboard can affect people’s livelihoods and happiness as well as the operational and financial health of the business. These data points are more than just pretty dots – they are people.

We also want to make sure our dashboard is easy to use. Think about digital affordances. We want it to be clear what happens when someone interacts with it. We can get fancy with bookmarks and editing interactions in a Power BI report. But does our intended user understand what is shown when they click a button that loads a bookmark? Can the intended user easily get what they need? Or do they have to jump through hoops to get to the right page and set the right filters?

Let’s say Sarah is a new manager at an organization that is trying to improve a high attrition rate, and she needs this information for a meeting with her boss and peers. She’s sitting in an online meeting using a 3-year-old tablet with 10 minutes of remaining battery life. Her two-year-old child is running around in the next the room. The group is discussing whether they should let some people go and then try to rebuild their teams. Can Sarah easily pull up the dashboard on her tablet and set the correct filters to see attrition numbers and retention factors for her team while trying to put on a brave face in front of her colleagues as she races against the tablet’s remaining battery time?

Visualizing the Coronavirus

Currently, it seems everyone in the data community wants to visualize the spread of COVID-19. Just look at the Power BI Data Stories Gallery. I get the appeal of using new and relevant data for practice, but consider your audience and the consequences of making it public. Do you trust and understand your data? Have you considered how the chart types and colors you choose can misrepresent the data? Who is it helping for you to publish your visualization out into the world? What message is your visualization sending? Is it unintentionally adding stress for your already stressed-out twitter followers? Most of us are not working with city officials or healthcare practitioners. We are visualizing this “for fun”. People are showing off Power BI/Tableau/D3 skills and not necessarily communicating clearly with purpose.

Your twitter friend/follower Frank is really concerned about the pandemic. His daughter lost her job at a restaurant. He’s worried about lining up projects for the next few months. And his wife is immunocompromised and in a higher risk group for getting COVID-19. He feels scared and helpless.

Your friend Dave is worried about his mother who lives alone a few hours away from him. He is bombarded by messages every day that say older people are more at risk of getting COVID-19. His mom says she is fine, but he wants her to come and stay with him. It’s all he’s thought about all day.

If you know nothing about epidemiology and don’t understand the response from various national, state, and local governments in your data, and you publish your viz with a choropleth (filled) map covered in shades of red, how will that affect Frank and Dave and everyone else who reads it? Did you add value to the COVID-19 conversation, or just increase confusion and fear?

Amanda Makulec published Ten Considerations Before You Create Another Chart About COVID-19 with some good advice, including the following.

To sum it up — #vizresponsibly; which may mean not publishing your visualizations in the public domain at all.
Amanda Makulec

Stress cases can be related to a crisis, mundane technology failures, or just situations that are stressful in the context of the user’s life. If you are visualizing data, remember there are people who may be interacting with our visuals in less than ideal circumstances. We need to design for them as much as for our ideal use cases.

If you have real-life examples of designing for stress cases in data visualization, please share them in the comments or tweet me at @mmarie.

Consulting

So You Want to Be A Business Intelligence Consultant

June 27, 2019September 24, 2020 Meagan Longoria

I’ve had a few people ask me recently for advice on getting into business intelligence/analytics consulting. I have been in consulting for 6+ years and have worked for 3 different consulting firms, so I’m sharing my thoughts and experiences here in case they are helpful to someone else. My first response to people asking this question is usually to clarify what they mean by consulting.

What do you envision when you think about consulting?

Do you want to be an independent consultant, work through a placement agency, or work as a full-time employee (FTE) for a consulting firm?

Life looks a little different based upon your answer to this question. I have chosen to work for a consulting firm for a few reasons:

I like the stability of a salary and paid time off (vacation, holidays, sick days)
I don’t have to do my own accounting/taxes/collections
I’m not solely dependent on my sales efforts to bring in work
I like having smart coworkers that are in the trenches with me

If you are independent, you are responsible for everything. You must take care of (do yourself or outsource) your own accounting, legal, taxes, collections, sales, etc. Even if you outsource some of these functions, you need to stay somewhat involved – you can’t just throw your financial documents over the fence and wipe your hands of them.

And if you aren’t doing billable work and getting the client to pay you, you aren’t getting paid. This means you need some financial reserves to cover slow months.

My independent consultant friends tell me that sales takes up much more time than they had initially anticipated. They are always working to line up that next engagement to avoid having large gaps between projects. It takes work to build up a sales pipeline. Sometimes you can mitigate this by teaming up with other independent consultants or companies to have a lead referral agreement. They can refer clients to you when they need help in your area of expertise. But there is usually no guarantee of work from these other parties, and sometimes they take a cut of the revenue for sending the work to you. You can outsource a lot of things, but sales is rather difficult because you need the salesperson to understand what you do, the value it provides to clients, and what your values and preferences are.

Another issue you face as an independent consultant (and sometimes as a consultant for a very small consulting company) is how to get interesting projects that require multiple people. Let’s say you have found a potential client that wants to do some really cool analytics, but the project requires three people to work together. You’ll need to have relationships with other consultants with whom you can team up to work the project. And even if you have good people you can work with in general, the work needs to fit into their schedules .

As an FTE, I am still responsible for some sales efforts, but we also have a salesperson and other employees to help. And if I don’t sell anything, I still get paid. This is a great thing for my mortgage and my stress levels.

But as an independent consultant, you also are your own boss. You get to make all of the decisions about how and where to spend your time, what office and tech supplies to purchase, what your website looks like, how much vacation you can take, and who you want to do work for. Want to take a month off to travel the world or spend time with your family? You don’t need anyone else’s permission to do that. But you won’t be getting paid if you aren’t working. One way to mitigate this is to create content that can be sold so you have some passive income in addition to your normal consulting engagements. An example of this is creating a business intelligence course and selling it on your website or through an online learning/education company. You could continue to get revenue/royalties as people purchase the course. But do your homework to get realistic expectations about how much extra income this would mean relative to the time it takes to create and update the content.

If you want to be a contractor where you do full-time, often 3- to 12-month, engagements with a company, you can get your own work or you can go through placement firms. Some placement firms offer benefits and some guarantee of work in exchange for a share of the income resulting from your placement. Others take a flat fee (either from you or from the hiring company). This type of consulting is usually paid based upon an hourly rate.

Do you want to be a consultant who is more project-based where you have a specified scope and budget, and you may work for multiple clients at one time? Or do you want to be embedded full-time in an organization?

All consultants/contractors must complete (most of) the tasks and projects they take on, but managing scope and budget are special skills. Some people enjoy that challenge while others do their best to avoid it. If you are essentially a contractor who spends your time with a single client and does whatever comes up, you may have to spend less time and effort managing scope and budget. If your work is more project-based, this becomes an important part of your work.

If you do project-based consulting, you may occasionally have to work with multiple clients at once. This means you have to do a lot of context switching. I have had days where I worked on a Power BI sales report makeover for Client A, helped a coworker with some DAX over lunch, and built a data warehouse with product inventory data in Azure SQL DW in the afternoon for Client B. Clients don’t really think about what we do when we aren’t working for them. They are expecting us to mentally pick right back up where we left off when we get back to them and remember all the project and organizational details. I rather enjoy that variety, but I know that it gets stressful and isn’t a good fit for everyone.

Another aspect of project-based work is the amount of time you get to stay on with a client. Some consultants focus on implementations or health checks and then move on. They aren’t there 6 months later to see how things are going with that new system they implemented, unless the client calls them back. There is good and bad in this situation. The consultant may get a lot of experience with building systems/performing health checks in a short amount of time compared to an FTE not in a consulting role. But they may not be around to understand and experience the consequences of their design, unless they client calls them back. You can always work out retainer or support agreements to hedge this a bit, but it is up to your organization and the client to do so.

Project-based work can also mean you have less stability in your life. It’s difficult to anticipate exactly when an engagement will start or end, when you will need to travel, which nights you may need to work late. But project-based work can also offer exciting opportunities, a great variety of technical work, and the opportunity to learn about different companies and industries within a short amount of time.

What would work best for you?

There isn’t a single right answer to these questions. It’s about what would give you the income, benefits, lifestyle, and type of work that you want.

Consulting, Data Warehousing, Microsoft Technologies

Ten Ways To Help Your BI Consultant Be Successful

January 29, 2018September 24, 2020 Meagan Longoria

I’ve been working in the field of business intelligence for over ten years, as a consultant for over five years. One thing I’ve learned from that time is that consultants need the client’s help to complete a project on time and on budget. Even if the consultants are doing the bulk of the work, project owners and stakeholders have a large impact on the project.

When you hire a business intelligence consultant, both you and the consultant want to see your project succeed. While a good consultant can guide you through important decisions and manage a BI project in addition to doing the technical development work, they need your help to get the project started off right and to continue to meet deadlines and requirements. A BI project requires collaboration between the consultant and the client. It’s usually not the type of thing you can throw over the fence and get back a satisfactory solution. We need to understand your business and how you think and talk about your data in order to give it meaning and make it accessible in a data model or report.

In my experience, we consultants write assumptions and project prerequisites into Statements of Work (SOWs) and mention them on planning calls, but we don’t always emphasize how important they are to project success. And we’ll often work around missing prerequisites to try to keep to the project schedule as best as possible, to varying degrees of success. As a client, your organization has allocated budget to your BI project that could have gone to other priorities. We understand this and are motivated the use that budget to accomplish your project goals, but we often spend a lot of project time overcoming obstacles related to lack of access to environments and technical assets and lack of client/stakeholder involvement. The problem/opportunity is already challenging or you wouldn’t need a BI consultant, so why not do what you can to remove barriers that are within your control and help steer the project toward success?

With the help of a few co-workers/work friends I’ve compiled a list of ten ways you can help your BI consultant (and therefore your BI project) be successful. Special thanks to Josh Roll, Melissa Coates, and Levi Syck for your input and feedback on this list.

Have your data sources ready before you start. A good consultant can get started with design and stub things out or use fake data, but it will take us longer and quality will be questionable until we get our hands on real/realistic data.
Work out data access (network/Azure/Power BI logins, VPN access, database access, etc.) for your consultants ahead of time, not on the day of project kick-off. So many projects get stalled at the outset because the consultants don’t have access to the data and environments they need.
Help your consultant understand any political/departmental boundaries too. If you know that some department owns some needed data and that they are possessive about it, be up front and consider ways to get them involved, rather than leaving us to go and blunder through, possibly stepping on toes in the process. Provide context for the project. How does it help your organization achieve its larger goals? Who came up with the idea? Has something similar been tried before? Consultants get to do similar projects at different companies, so they bring good experience and ideas for overcoming technical and organizational challenges.
Make sure you understand the time commitment of a BI project and make sure project owners, technical contacts, and subject matter experts can be available as needed. Be involved throughout the project, but especially during user acceptance testing to ensure our solution covers your use cases.
Be able to define success criteria. You may not be able to dictate all the business and technical requirements, but you should be able to work out what success looks like on your project. Your consultant can help you define success, but things will go better if you have given this some thought beforehand.
If you have existing database or ETL frameworks or naming conventions you would like to be used, make sure they are documented, or make someone available during the first few days of the project to explain them and answer questions. Don’t leave your consultant to guess.
If your consultant sends you project planning and requirements documents up front, rather than after the fact, they are using these documents to establish understanding and agreement. Take the time to read them and ask questions. As consultants, we have a limited amount of time to become well acquainted with your data and use-cases, and we operate under the assumption that you will steer us in the right direction if you see us veering off the path.
Be aware of your data hygiene. If your data is incomplete or dirty we’re going to need your help deciding how to handle it.
Plan for an iterative development process. Know that everything probably won’t be perfect the first time. We probably can’t fit everything into the initial scope. Make sure there is room in the timeline for testing and rework. Generally, iterative projects have a higher chance of success than very large big bang projects. You can still get to the larger vision, just know that we will probably ask you to break it up into smaller, more manageable chunks. Also, be prepared to make decisions in the face of ambiguity. Not all architecture and design decisions can be made with absolute certainty. But they often need to be decided to move forward and can be adjusted down the line, if necessary when priorities change or new information comes to light.
Identify who will support the solution after the consultant is gone. Involve that person or team early. It’s better for the support team to learn about the solution over a period of weeks or months, rather than cramming everything into a knowledge transfer session and a document at the end of the engagement. If you don’t have anyone to support the solution, be honest with yourself and request a separate support contract up front and factor it into budget requests or allocations.

I hope you’ll find this list useful in planning your next engagement with a BI consultant. If you are a BI consultant or have worked with a BI consultant, please leave a comment about what you would add to this list.

Category: Consulting

Types of data consulting engagements and what you can expect from them