SQL Tact: Moving Into Consulting 101 - Part 4

This is part four in a five part series this week, Moving into Consulting 101.

Today's topics give you a numerical advantage in consulting. All have a common theme: don't wing it. Try to formalize processes that deal with how you account for and plan your time.

Maturity in terms of project estimation, project execution, and time accounting are required for a successful consulting career.

from Pixabay

The Process of a Consultant

Make estimation a science

Contracts should not be signed based on estimation of "ballpark figures" or WAGs (wild-ass guesses). Agile methodology involves regular sprint planning meetings, where tasks are devolved into small components, usually no larger than 8 hours of work. Sometimes the hours for any given task must be a power of 2 (1,2, 4, 8), sometimes they must be primes (1,2,3,5,7) but the idea is that we are forcing projects to be broken down into many small tasks, which are easier to estimate. But you don't have to practice Agile or Scrum or similar methodologies to practice this pre-project deliverable.

Regardless of your field or expertise, strive to make your estimation as detailed as possible, breaking down tasks into individual activities that fit inside of a day. In other words, nothing should take "about a week".

Don't forget to include other tasks aside from your effort in the project's estimate. Does this project need a Project Manager? Quality Assurance or testing? Meetings with Subject Matter Experts? Are you accounting for internal standup meetings and client-demo meetings? Once the work is done, are you accounting for migration time, post-migration support, knowledge transfer meetings and documentation?

Finally, as painful as it sounds, you should review your pre-project estimation against your post-project timeline. In any project post-mortem, we should review how accurate our estimates were and why they were off. They will be off. It's okay. Highly experiences senior resources will consistently miss on duration estimates because project estimation is hard. It's really very hard, we can get better at it only through practice, through planning small atomic blocks of time, and through honest post-mortems. So save your pre-sales estimation spreadsheets for careful examination post-project, and learn from them.

Practice rapid prototyping

This isn't a blog post extolling the virtues or buzzwords of Agile methodology, there are many others to do that. This is something you can use whether or not you practice Agile or scrum, or organize your team's planning meetings and daily standups around that culture.

There is one important key deliverable of Agile that clients and end-users become keenly aware of: rapid prototyping. You should develop a habit of going back to the client regularly to show progress. This allows the project to make micro-corrections instead of major changes. These course adjustments will only start when the client sees whatever it is you're working on. You want that to happen sooner rather than later.

In consulting terms, rapid prototyping also allows for ample opportunities for project scope conversations, which a good consultant turns for new features and hopefully change orders for additional hours. This isn't underhanded or conniving. Clients don't know beforehand the full extent of what would make a their project successful. Delivering a more full-featured product will be judged more positively in the end.

I'm not just talking about custom app development. You can plan for rapid prototyping in business intelligence, process documentation, training/development content, runbooks, personnel evaluations, even the scoping and estimates for the project itself.

In short, don't take the initial work specs, work on it for a few weeks, then show a demo. You should be demoing your work to the client every other week, if not more often. This isn't as cynical as it sounds, but no customer has ever accepted a deliverable matching only the initial description.

There are always project changes from the original plan, some predictable and some thanks to the whimsy of the client. "Scope creep" is definitely a thing that happens, but this is a manageable problem when you have good project controls in place. In fact, scope creep can be advantageous for a consultancy if it results in change orders to add scope and duration to the project.

Whether you accomplish rapid prototyping via Agile or scrum or neither, just make sure you are keeping your project on track with frequent check-ins with the customer.

Learn the skills of a project manager

Don't assume all your projects will have a PM doing that "project management work" for you. You need to make sure PM-type tasks happen regardless.

Across the many projects over 12 years, I worked project scopes large and small, some with a PM and some without.

On many projects, I was doing the status communication myself anyway, so naturally the client came to me for status communication and follow-up. Clients might prefer to hear technical status communication straight from the resource, without the PM's filter. Regardless, keep your PM in the loop at all times, if you have one.
When my project had a PM resource, more client communication ran through them, especially for documentation. (In some of those cases, the PM was absent or uninvolved, and the task of managing the project fell to me anyway.)
Many smaller or shorter duration projects had no PM at all. Perhaps the client knew me so well that I was entrusted with keeping the project on track. Perhaps clients would refuse to be charged for my consultancy's PM, and would instead provide their own PM. (In many of those cases, the client-provided PM was absent or uninvolved, and the task of managing the project fell to me anyway.)
Sometimes, a PM would be assigned but have a only fraction of the total hours for their services, maybe 2-4 hours a week. This isn't enough time to do much more than gather progress notes, sit in on a meeting, and provide a status update. (Many of the tasks of managing the project fell to me anyway.)

Having a well-invested Project Manager on the project was certainly helpful and relieved some of my workload, but as you can see, it didn't always work out that way.

That's when I had to be my own project manager. That's when it became paramount that I had a good understanding of what had been agreed to and on what timeline, so that I could:

Track progress versus the deliverables we're contractually
Account for hours/dollars spent versus the cap
Hold cadence meetings with the client
Wrap up the project in style, reviewing all deliverables
Hold a wrap-up meeting to get signoff
Ensure SLAs are met
Track bugs, change requests, QA feedback
Go to Sales with opportunities for follow-up projects
Create knowledge transfer documentation detailing everything delivered

Later we'll discuss the Statement of Work document, which is important for you to have access to and review. A SOW is a contract that contains everything that the consultancy has promised, when, and for how much. It may fall to you to make sure your consultancy has delivered everything in that document. Pay special attention to end-of-project documentation requirements.

from Pixabay

Vocabulary

Common project billing concepts

T-Shirt Size = An estimation tactic that forces all tasks to fit a size of hours. For example: XS (.5 hour), S (1), M (2), L (4), XL (8). The Key: anything larger than XL needs to be broken down more granularly. This forces you to analyze deliverables and anticipate complications sooner, and a project to contain a long laundry list of tasks. This is a good thing. Your consultancy may use different values or strategies for this same general idea.

Cadence = An overused buzzword for sure. The idea here is that you have regular status meetings (every week perhaps), and that the meetings occur in a standardized way. In a cadence meeting, you'll probably see questions answered around progress, metrics towards deliverables, budget vs actual spent.

Change Order = This may be called different things in different places, but it's an amendment to the original contract, or Statement of Work. If the client asked for ABC and now wants D and E, a change order contains the details, deliverables, schedule, and additional budget to deliver D and E. Change Orders often represent new money to be spent, so clients may have hesitancy or long processes for approval. That doesn't mean work should stop, but we cannot deliver on D and E until we have a Change Order.

Delivery or Operations = The boots on the ground. The people clicking the buttons, writing the code, creating the product, providing the solution. Deliverables are delivered by these consultants who have subject matter expertise: recommendations documents, code, processes, improvements, training, service, etc.

Sales = The opposite of delivery. We'll talk about this in the next post in this series.

This is part four of a five-part series on Moving into Consulting 101.

Got comments, questions, or guide for your fellow consultants? Comments are welcome below.

SQL Tact

Thursday, March 25, 2021

Moving Into Consulting 101 - Part 4 - The Process of a Consultant