6.2 The Consulting/Analysis Life Cycle

There are twelve steps in the consulting life cycle (see Video 2.0 – The Consulting Life Cycle and [51] for details).

  1. Marketing – getting the word out.

  2. Initial contact – start discussions with prospective clients.

  3. First meeting (and meetings) – committing to write a proposal for the client.

  4. Assembling a team.

  5. Proposal and Planning – laying out what can be done for the client.

  6. Contracting, Insurance, IP – if the client agrees to the proposal, this step is crucial: do not start work until this step is cleared up.

  7. Information gathering – may include data collection and cleaning, meeting with domain experts and in-house specialists to get a sense of the context.

  8. Analysis – where quantitative skills come in to play.

  9. Interpretation of results – this is what the client actually cares about.

  10. Reporting, dashboarding, deployment – there are often multiple deliverables along the way.

  11. Invoicing – required in order to get paid.

  12. Closing the file – conducting a post-mortem with the client and with the team, and deciding what is next.

In this section, we dig a little deeper into each of the steps.

6.2.1 Marketing

Marketing is required to let prospective clients know that an individual or group is in business (as consultants), that they possess a specific set of qualifications, and that they are looking for projects on which to work.

There are numerous marketing approaches:
  • word-of-mouth

  • online

  • event

  • newsletter

  • article

  • content

  • niche

  • reverse

  • etc.

 
Obviously, not all of these methods are applicable to every consultant and to every context. The principle underwriting marketing is simple: if prospective clients do not know that consultants exist, the latter cannot be found.72

In a broad sense, marketing is anything and everything done by a consultant in order to legitimately “get an in” with a prospective client and to convince them to hire their services. As with dating, attempts to get in “illegitimately” are usually regarded poorly and can easily backfire.73

Large consulting firms typically have marketing teams or departments – that is to say, individuals who are dedicated to finding clients and projects.

In smaller firms, marketing is usually done by the consultants themselves. Individual consultants and sole proprietors often join up with one another to avoid duplicating marketing efforts and to minimize associated costs. Keep in mind, however, that this requires a certain amount of business compatibility and ideological alignment.

Marketing avenues should not be viewed in a fixed manner – not only are they constantly changing with the advent of new technologies,74 but personal preferences and the appropriateness of a given approach may change over time.

And while good marketing is necessary to consulting success (whatever form this may take), it is not a sufficient condition; there is a marketing point of diminishing returns, after which the results are not worth the effort.

Which avenue should a consultant select? The following questions are worth asking:

  • does the avenue give a consultant an “in”?

  • can it convince a client to hire the consultant’s services?

  • what is its true cost (time, financially, energy)?

  • what is its initial vs. ongoing investment?

  • what are the risks associated with it?

  • are there universal guidelines to the approach?

As alluded to previously, what works for one project, one client, one consultant may not work for another – beware the tyranny of past success!

Marketing Materials

Beginning quantitative consultants could benefit from some of the following avenues:

  • current and customizable project-based CVs

  • client testimonials (letters of reference, etc.)

  • portfolio (online, offline), including personal and pro bono projects (GitHub repository, etc.)

  • active social media presence

  • updated and functional website/landing page

  • blog articles/white papers on variety of topics

  • brochures and business cards

  • attending conferences and networking activities

  • adverts

  • etc.

We shall provide additional details for a few of these.

Project-Based CVs contain two main sections:

  • Traditional CV (contact info, skills, selected achievements, relevant experience, education and personal development, personal)

  • Relevant Project Experience (list, role, project description, related reports and presentations)

Other items can be added, depending on the context (publications, teaching, etc.). The traditional section should be no more than 4 pages (note the suggested section order). Projects in different domains could also be used to showcase successes and breadth of knowledge (see [52]).

Social media platforms include:

  • LinkedIn (consider accepting invites from people you don’t know, expand your network, post regularly)

  • twitter (RT articles/posts of interest, with a commentary; get to know who the experts in the fields are and follow them; post regularly)

  • Facebook, Instagram, TikTok, etc.

With an online presence, there might be a need to separate your personal from your professional online identities; it is important to avoid the common pitfalls of online use (trolling, flame wars, lousy/generational spelling, etc.), and to keep up with new tools.

Blog articles can be used for:

  • content aggregation;

  • interacting with community;

  • pushing content;

  • showcasing communication, technical skills, and interests.

These are not journal articles, so effective communication is key.75 Examples can be found on the Data Action Lab blog [53].

Goal: get a prospective client interested in your services.

Consult Video 2.1 – Marketing and [51] for details.

6.2.2 Initial Contact

If a prospective client expresses an interest (no matter how faint) in working with a consultant, whether through email, a phone call, or some other approach, the consultant should:

  • immediately dedicate a project number, an email folder, and a folder in their file structure to the potential project;

  • capture and verify email addresses and phone numbers as soon as possibly;

  • respond to advances promptly (without seeming too desperate), and

  • show interest in the project, even if the subject matter is not to your liking or if you are not an expert on the required methods

It is too early to turn down a client at this stage due to a lack of interest or qualifications – if a project must be turned down, it is much preferable to invoke lack of availability or to suggest another lead instead.

Goal: gather some initial information about the project and set-up a meeting to discuss it in detail.

Consult Video 2.2 – Initial Contact and [51] for details.

6.2.3 Client Meetings

If the client agrees to a meeting and the consultant has a meeting space, the client can come to the consultants. If so, the consultant needs to make sure that a private space is available, with:

  • wi-fi connectivity,

  • plenty of electrical outlets,

  • projectors,

  • water/coffee/pastries/muffins,

  • A/C or ventilation in the summer, etc.

If the consultant does not have a meeting space on hand, they should instead secure a shared meeting space or simply offer to go to the client (that should be the first option offered, as a courtesy). Furthermore, they should:

  • bring a laptop computer (with battery pack or electrical cord);

  • bring identification;

  • go to the bathroom before you enter the client’s office;

  • refrain from being late and arrive 15 minutes early (scope the parking/busing situation), and

  • dress appropriately (business, business casual?).76

Either way, (e-)business cards/marketing material should be available, to be traded before the first meeting starts. Eye contact and small talk (weather, sports, news events, etc.) should not be neglected – consultants are being gauged not just as technical experts, but as human beings as well – no client wants to work with a robot.

But it is important to remember that the “interview” process goes both ways; the consultant is also trying to determine if they want to work with/for the client. Before a contract has been agreed to, everything is still only tentative; it is important to get a sense for client-consultant compatibility.

In general, it is preferable to let the client take the lead in describing their situation and needs.

The consultant should:

  • take notes (or have an assistant take notes);77

  • not let misunderstandings (acronym, details specific to their industry or company, etc.) go unresolved – ask for clarification;

  • never interrupt the client – instead, they should wait for a lull or a natural point in the conversation to make contributions and show that the client’s needs and the underlying situation are understood;

  • ensure the first meeting is not about the consultant (or at least, very little of it is) – more listening, less talking.

Clients sometimes ask consultants to provide solutions on the spot – consultants should not acquiesce to this, and should NEVER commit to a project, to a price, or to a timeline at the initial meeting.

If pressed, they could instead say: “I’m going to bring this information back to my team and we will evaluate the project’s feasibility. You will hear from us within \(x\) days/weeks.”

Goals:

  • get a sense of the project’s feasibility and suitability;

  • gather information about data sources and quantitative requirements, and client’s understanding of same;

Consult Video 2.3 – Meetings and [51] for details.

6.2.4 Assembling the Team

Will consultants be working on this project alone? With a team? What roles are needed on the team? Who is available?

There are pros and cons to both individual work and team work.

Individual Work
  • bigger share of revenues for the consultant;

  • resource management easier to handle;

  • no need for team meetings;

  • latitude in accepting/rejecting projects;

  • nobody tells anyone what to do (except for the client, perhaps);

Team Work
  • more available resources, so project can be completed quicker (although this is only true up to a point in practice);

  • more knowledge/ideas at the team’s disposal;

  • only one person needs to interact with client;

  • managing egos and personalities can be difficult, at times;

  • there is psychological strength in numbers (in theory, at least).

Our experience suggests that teams can usually achieve more, but that this could come at a price: for some consultants, the level of satisfaction derived by a project might be affected by how much compromise was needed to see it through.

Goal: find competent and pleasant people to work with.

Consult Video 2.4 – Assembling the Team and [51] for details.

6.2.5 Team Meetings

Once a team has been assembled, it becomes crucial to plan for team meetings. Nobody likes those,78 but they are crucial to the project’s success.

The designated meeting lead should prepare an agenda and and is responsible for the team sticking to it; that step is needed because team meetings can easily become time sucks. Team members should take such meetings seriously; remember – the project’s success depends on every consultant doing their work!

Goals:

  • keep the project is on track;

  • exchange vital info between teammates (changes to the work plan, new discoveries by other members, etc.);

  • keep team lead abreast of progress.

Consult Video 2.3 (Reprise) – Meetings and [51] for details.

6.2.6 Proposal

If, after deliberations with the team, the project is deemed feasible (by the consultants and the clients), a proposal must be presented to the client.

The proposal is the foundation of its eventual success – it is the opening salvo in the negotiation with the client.79

One of the challenges facing consultants is how to gauge the value of the services they offer – we tend to sell ourselves short. The proposal justifies the monetary demands to the client; it also helps limit what is known as scope creep.

Consult Video 2.5 – Proposal and Project Planning (1:05-1:40) for details.

A proposal should read as a letter to the prospective client. Its content may change depending on the specifics of each project, but the following topics should figure in the final document:
  • Background

  • Objective and Scope

  • Methodology

  • Milestones and Deliverables

  • Schedule and Assumptions

  • Resources and Costs

  • Travel and Invoicing

  • Appendices – Suggested Workplan; List of Former Relevant Projects and Clients; CVs and Bios, etc.

 
Consult [52] for samples and Video 2.5 – Proposal and Project Planning (from 10:50-13:25) for more details on this topic.

Background
  • introduction;

  • state what consultants understand of the client’s organization (research this).

Objective and Scope
  • state what consultants understand of the client’s problem (go back to client to clarify if needed);

  • delimit the tasks (“we will do …”, “we will not attempt to do …”); the client may require options.

Methodology
  • suggest a series of steps / methods that the consultants will follow; the idea is to show the client that the team has already started thinking about their problem;

  • add a caveat that the data will ultimately be driving what method is used.

Milestones and Deliverables
  • explicitly list the important steps and deliverables that will be produced for the client (prototype, final report, weekly progress reports, dashboard, executable code, etc.).
Schedules and Assumptions
  • provide a timeline for the milestones and deliverables, assuming that an agreement is reached by a certain date, or that the data is available by a certain date, etc.;

  • use relative dates if the client has deliverables or responsibilities for the project as well (better to err on the side of caution and deliver on time and below cost than the other way around!);

  • establish the project authority on both the client and the consultant sides.

Resources and Costs
  • list the resources that will be assigned to the project, with a short justification to reassure the client that the consultants are qualified to work on their project;

  • list the projected cost for each option (referring to the workplan as needed), with HST info;

  • reassure the client that they will not need to pay for work that is not done;

  • state that if more work needs to be done due to a change of scope, issues with data quality, or some other client issue,80 the consulting team will wait until approval before starting the new work (communication with the client is crucial!).

Travel and Invoicing
  • state what traveling costs will be charged to the client and that more expensive jaunts will only be undertaken with the client’s approval.

  • state the invoicing policy – monthly/at milestones/upon completion, etc.

Suggested Workplan
  • provide a table with tasks and steps (follow the methodology), expected time expenditure and corresponding costs, as well as timelines;

  • produce a total estimate for the project (include the tax information).

Credentials and Credibility
  • add a list of previous clients for references;

  • add project-based CVs and short bios of team members;

  • add a list of other services offered by your team.

Goals: let the client know

  • what is understood of the problem at hand;

  • what the consulting team can do for them, and

  • what they can expect in in return.

The Client Dance

Assuming that the proposal is sent to the client within the agreed-upon deadline you have provided them, the next step in the process is the client dance.

In general, the clients do not know (nor do they need to know):

  • how busy the consultants are;

  • how many projects they have on the go, and

  • how many proposals are up in the air.

Conversely, consultants do not know:

  • the project’s priority for the client;

  • the procurement challenges, and

  • if multiple proposals were requested from different consultants.

It is the absence of this knowledge that makes the client dance difficult to navigate. In the proposal, the client is given a deadline by which to respond in order to guarantee the availability of the consultant’s resources:

  • if they respond in time, then the next step is to fine-tune the proposal;

  • if they respond after the deadline, then the consultants need to reassess the situation – perhaps the promised resources are not available anymore?;

  • if they do not respond, the consultants have to decide to either poke them or to let the project go.

If the client is not responsive, remember the dating analogy – sometimes the client dance is a negotiation tactic, but sometimes “they’re just not that into you.”

So from the consultants side of things, the important questions to answer become: how desperate are they to get a project? How flexible are they? Can they afford to wait? Can they afford not to get the right terms?81

Consult Video 2.5 – Proposal and Project Planning (from 13:25 onwards), for details.

6.2.7 Contracting and IP

After some back and forth, the consultants and the client might agree to a proposal – this is a required step in the process, but it does not constitute a binding legal document.

Consultants should never start work on a project until a legal contract has been signed by both parties. Some organizations insist on using their own contracts – some negotiation is possible, but they are not always willing to budge. Either way, it is crucial that consultants DO NOT SIGN A CONTRACT THAT THEY DO NOT UNDERSTAND OR AGREE WITH.82

A contract sets out the roles, responsibilities, and legal obligations of both parties; it contains a number of clauses, distributed in a number of sections:
  • Identification of parties

  • Acknowledgement of Processes by Parties

  • Definitions

  • Charges

  • Term

  • Conditions

  • Payment

  • Materials

  • Confidential Information

  • Warranties and Liability

  • Force Majeure

  • Termination

  • Notices

  • Conflict Between Documents

  • Dispute Resolutions

  • Waiver

  • No Permanent Relationship

  • Unenforceable Provisions

  • Governing Law and Jurisdiction

  • Singular and Plural

  • Headings

  • Amendment

  • Language

  • Fax and Counterparts

  • Signatures

 
Contracts should never be prepared automatically – the clauses and sections may need to differ from one contract to another, although some of them may be used more frequently (see [52] for an example).

One aspect which is not explicitly listed above is that of intellectual property. Who owns the results of a consulting project? Most reasonable parties would conclude that it is the client; consequently, non-disclosure agreements (NDAs) are often required before a contract can be enacted.

But who owns the methodology? The approach? Can consultants re-use code for another project or publish the methods? Can an individual consultant use a method she developed as part of a team for her own work? Is it even possible for mathematical, statistical, analytical work to be patented or made proprietary?

This might seem like a frivolous question to ask at this stage, but consultants should take the time to reach consensus on this topic with their team, and with the client – this will save everyone a lot of heartache down the road.

Goal: make the eventual consulting work as simple as possible by removing the focus on anything but the quantitative analysis.

Consult Video 2.6 – Contracting and IP and [51] for details.

Insurance

From the client’s perspective, a consulting project only has three possible outcomes, of which only the first two are every (ideally) in play: either

  • the consultants exceed the expectations (managed via the proposal and open communication), A+;

  • the consultants meet their expectations, A\(-\), or

  • the consultants fail to meet their expectations, F.

Given an “F”, the best case scenario from the consultant’s perspective is that the client will simply be disappointed and send future projects to other consultants; the worst case scenario is that they think that the consultants also failed to meet their contractual obligations, opening themselves to legal action.

Professional insurance against this (inevitability?) is a must.83

6.2.8 Project Planning

While no actual work should be started before an agreement with the client is finalized, consultants should still start planning the project as soon as they start working on the proposal (consult Video 2.5 (Reprise) – Proposal and Project Planning for details).

Goal: consultants need to meet the project’s (often) tight deadline without exhausting themselves in the process, so planning ahead of time will help them hit the ground running!

Note that project management is often taught as separate course in business schools and there are various list of available references (see [54], for instance) – it is even possible to get certification (as with [55], say). Such minutia is outside the scope of this modue, however.

For quantitative consultants, perhaps the most important piece of advice is to prepare a timeline for tasks/deliverables, incorporating:
  • teammates’ (and external resources’) availability;

  • projected delays;

  • client bottlenecks;

  • unexpected turns;

  • holidays;

  • client deadlines;

  • simultaneous projects and courses;

  • work-life balance, etc.,

 
while keeping Hofstadter’s Law in mind:

“It always take longer than you expect, even when taking Hofstadter’s Law into account.” [56]

Consequently, consultants should be prepared to revisit their workplan periodically, especially when preparing progress reports (internal and external) – this should not be seen as a failure, but rather as normal and expected course corrections, which occur in all project work.

Weekly Schedule

It is impossible to plan the project work without having a good sense of the team members’ availability (an example is provided in Figure 6.2).

An example of weekly time availability for students and professionals.

Figure 6.2: An example of weekly time availability for students and professionals.

There is but a finite number of hours in a week, and each of us has responsibilities outside of work, including some necessary downtime and rest.

There is no value in creating a superhuman workplan that cannot be met – consultants have to be realistic if they want to deliver on time. Failure to agree to a mutually acceptable schedule means that the project should not go forward.84

Workplan

If the resources are available, the first project planning step is to come up with a workplan that uses high-level phases, with item names that follow the proposal’s methodology.

Once these have been nailed down (with expected durations), the next step is to break down into various task categories and sub-tasks, with potential deliverables, timelines, and assigned team members associated to each task.

This is as much an art as it is a science, and it can take a few sub-par projects before consultants get the hang of it. Experienced project leads can provide advice, if required.

Consult [52] for samples, and Video 2.5 (Reprise) – Proposal and Project Planning for a short explanation.

6.2.9 Information Gathering

In the proposal, the consultants have demonstrated their understanding of the client’s organization and of the project.

But until the consultants actually start working on the project, that understanding may, at best, remain theoretical.

Practical (and actionable) understanding can most often be gained through

  • field trips;

  • interviews with subject matter experts (SMEs);

  • readings;

  • data exploration (even just trying to obtain the data can prove a pain),

  • and other similar things.

The client is not a uniform entity – it is conceivable that (some of) its data specialists and SMEs will resent the involvement of external consultants.

Goals: this stage of the process is a chance to show the various client entities that the consultants are on their side; it is also a chance to gather valuable information that was not publicly available prior to the start of the project. This can best be achieved by

  • asking meaningful questions;

  • taking an honest interest in the SMEs experiences and expertise, and

  • acknowledging their ability to help.

This is also the consultants’ first chance to identify gaps in knowledge,85 which can sink a consulting project if they go undetected until they are remedied.

Much more will be said on the topic in Section 7.2.2 of Data Science Basics – its content should be thoroughly understood prior to embarking on this step of the process.

Consult Video 2.7 – Information Gathering and [51] for additional details.

6.2.10 Quantitative Analysis

If everything else has fallen correctly into place, consultants should now be itching to conduct quantitative analyses.

Naturally, we assume that consultants and analysts have expertise in one or more of the following technical areas:86
  • data collection;

  • data processing;

  • data visualization;

  • statistical analysis;

  • data science and machine learning;

  • optimization;

  • queueing models;

  • trend analysis and forecasting;

  • simulations;

  • etc.

 
This is where the bulk of the work comes in, and where quantitative consultants (as opposed to regular consultants) and data scientists get to shine.

Goal: the quantitative consultant’s job is … well, to get the job done. The time for dilly-dallying is long gone.87

6.2.11 Interpreting the Results

When the analyses have been run, results are obtained. Clients are not actually interested in the results so much as they are interested in insights.

Actionable insights require results that can be interpreted and used by the client.88 Providing the deliverables correctly is surprisingly complicated: the only way to get this fact trough to learners is through practice and experience.

The case study write-ups available at [51] focus on the interpretation of results and could be used as a source of inspiration – as is often the case, none of those projects required an thorough understanding of sophisticated methods.

Goal: figure out what is useful for the client to know about the analysis outcomes, and translate your results accordingly.

6.2.12 Reporting and Deliverables

If all has gone well, the project is now coming to an end.

Deliverables are concrete products provided by the consultants to the client in their search for actionable solutions. They constitute a type of proof that the work has been done.

They might include:

  • deployment (code, software, apps), pseudo-code, conceptual ideas;

  • literature review, case study write-up, recommendation(s), expert advice, popular account;

  • progress reports, minutes of client meetings, notes, quality plan;

  • final report, presentation, cleaned-up dataset, poster, executive summary, dashboard, user manual, white paper, technical article, etc.

Project deliverables depend on the client and on the project.

Consult Video 2.10 – Reporting and Deliverables and [51] for details.

Code, software, apps should be documented and tested prior to demos and delivery.89

Use programming guidelines and make sure that code is devoid of unprofessional comments and offensive variable/function names.

Progress Reports

These let the client know what has been done, what is being done, what remains to be done:

  • keep to the essentials – what’s new, what’s left to do, what SMEs are needed, timeline estimates, etc.;

  • frequency should be arranged with the client (not more often than weekly, usually);

  • can also be used internally (together with minutes and notes, for project management).

Final Report

The purpose of the project leads to the type of report. Typically, a final report contains at least the following sections (some can be lifted directly from the methodology):

executive summary, background, objectivem methodology, results, discussion / interpretation, recommendations, references.

There will be instances where the story of the project is important (popular accounts, say), but in most instances consultants should strive to use technical writing.

In either case, say what needs to be said, in a manner that is understandable and useful to the client.

The executive summary should include recommendations and highlights – it is directed at stakeholders and higher-ups who may not even be aware that the project has been undertaken.

Proof-read the report for spelling, grammar, and style; make the report appealing – forego fancy fonts and unusual font sizes. If you use mathematical symbols, consider using LaTeX or Markdown.

Samples, as always, are available at [52]. Consult Video 2.10 – Reporting and Deliverables, from 06:30 onwards, for more details.

6.2.13 Invoicing

In a sense, this step is the most important of the process: consultants cannot get paid if they do not invoice the client.

The invoices should be kept simple; the included line items should be aligned with the deliverables and the milestones described in the proposal (and/or its amendments).

Invoicing can take place

  • upfront, such as for training sessions, say;

  • at regular intervals, for (advisory or long-term work;

  • after milestones and deliverables, for modular projects;

  • upon completion, if the client is trusted, such as with a government department, or

  • some mixture of those.

Goal: consultants need to keep money flowing to cover expenses and pay salaries.90

Consult Video 2.11 – Invoicing for details.

Invoices should contain the consultant’s contact detail, separate line items for the various deliverables, a line for the applicable taxes, payment options, and a payment deadline (30 days, 2 months, etc.), and so on. Consult Video 2.11 – Invoicing, from 5:10 onwards, for details)

Clients sometimes drop off the Earth without paying the invoice (an argument in favour of regular interval or milestone invoices if ever there was one); in that case, consultants need to decide for themselves when they will pursue the matter through legal means.

It is not a pleasant thought to entertain, but consultants need to be aware that this can happen in (rare) instances. It could be preferable to simply walk away without being paid, while documenting what happened (with signed contract and proof of delivery) and reporting the client to the better business bureau. In other cases, legal action could be justified.

A number of factors are at play here, so there is no one-size-fits-all approach, but let us share the advice we were given when we started out as consultants: only take on a project if its failure would not end your foray into consulting.

6.2.14 Closing the File

The client has accepted the deliverables and has paid the invoices, and now the project is over. The last step in the project life cycle is the post-mortem, in which the team:

  • analyzes the project process;

  • identifies the high marks and the low points;

  • plays the what-if game (how could thing have been done differently, in hindsight?);

  • decides whether they would accept to take on another project with the client if the opportunity presented itself.91

If they are amenable to doing so, the consulting team could also consider conducting a post-mortem with the client.92

The goal of the (internal/external) post-mortem is not to assign blame, but to learn lessons that can be applied to future projects.

Consult Video 2.12 – Closing the File for details.


Every single project is different, without exception. The consulting life cycle can also differ from one project to the next, or from one client to the next, but on average, most of the steps highlighted earlier in this section will be involved.

References

[51]
[52]
[53]
Data Action Lab, IQC Blog, 2021.
[54]
Project Management Institute, PMP Reference List.
[55]
Project Management Institute, Certifications.
[56]
D. R. Hofstadter, Gödel, Escher, Bach: an Eternal Golden Braid. New York, NY: Basic Books, 1979.