Adopting & Adapting process
Your consultant has a process, you should consider adopting it.
Consulting clients is something I’ve done for many, many years. I’m no hardened expert at it yet, but I’ve noticed a few patterns over the years.
One is that consultants nearly always have a process for working on things. This isn’t because they’re obsessed, more often it’s out of a plea for sanity.
Chances are good that if they haven’t worked on something *very* similar to the task at hand, most consultants have seen something very similar thereto. Solving problems efficiently and having a wide range of experience is what defines a good consultant, which of course you already knew that since you’re brilliant.
A process about process — So meta!
Getting folks to the table
Consulting means collecting input from multiple sources, collating them and resubmitting that analyzed input back to collaborators and stakeholders. Oftentimes, they’ll ask for a list of interested parties, then ask if there are any other folks who should be included as stakeholders — this is often the consultant trying to tease out any individuals who would provide expert feedback, but might be overlooked as too busy, or non essential. Often enough, the folks working most closely with the software are non-management, newer employees. Having the CMO offer feedback on initial planning sounds tempting. However a frank discussion with the interns on the functionality and design will often bring surprising gains in effectiveness. Even better, when a plan can take advantage of and create the sense of grass roots buy-in, long term success is much, much more likely.
Working beats conceptual
Often enough, consultants will press pause on ideation and start building. This isn’t due to planning fatigue, on the contrary, many are happiest planning for every eventuality. What has happened is that further planning will have diminishing returns, that more understanding lies on the other side of implementation. Usually it’s a feature, something small and concrete — something that’s self reliant and can be shown off easily. There’s more than a few Three Letter Acronyms that map to this concept. Feel free to hype the feature using at least one of these: Minimum Viable Product, Proof Of Concept, First Pass, etc.
Gb are cheap, billing hours aren’t
There have been many times when I’ve gone around & around with a client on what looks like important distinctions on things like hosting the site, or using a preferred vendor. More often than not, consulting firms provide recommendations on providers not based on kickbacks or referral bonuses, but on hard won experience & trust gained working with that partner. I can count on two fingers the number of times a vendor has approached me with a referral program in exchange for shifting clients their way. When a consultancy hires out a particular section of the work, it’s to more efficiently utilize their resources. This usually means that the third party needs to be able to execute their part of the build process with as little hands on time as possible. Any extraneous effort to accommodate that third party could be used on billable tasks.
Good surprises vs. bad ones
It’s a gift to be able to estimate the level of effort required to accomplish a given task — Not all developers are granted this gift. In that case, get comfortable with asking for overestimates on tickets. The effect that can have on the sprint plan is nontrivial as number of tasks planned to be complete shrinks. Take a deep breath & remember that getting a few things done well is better than many things done poorly. Chances are good that if the tickets are completed before the end of the sprint/release cycle, then there’s time to add more to the existing scope of work, or to prepare the next cycle for even greater success.
Asking for a confidence interval is a better measure of how much time it will take. Getting a range of potential time completing a task sets more reasonable expectations. Gauging uncertainty in this way is less confrontational for the developer & allows them to create space for unknown issues.
Estimate in points, not hours
Estimating tasks in hours is a poor idea, in fact estimating time to completion on a big task is more often than not, a SWAG. Furthermore, the estimate depends highly on the expertise on the estimator, their familiarity with the surrounding codebase, previous experience with past estimates, ad nauseum.
Better idea, estimate the complexity of completion. Measuring & estimating task complexity is detached from deadlines, PTO, or switching developers mid-implementation. Using story points instead of hours is a staple of agile development I’ll leave it to the fine folks at Atlassian to further illustrate:
Teams starting out with story points use an exercise called planning poker. At Atlassian, planning poker is a common practice across the company. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just couple minutes) to understand the rationale behind different estimates. Remember though, estimation should be a high level activity. If the team is too far into the weeds, take a breath, and up-level the discussion.
Keep everything — there’s no such thing as “We’ll never use it”
Oftentimes even having a skeleton of existing process is enough to stir folks up into brainstorming improvements. Even a 20% proof-of-concept process illuminates a set of jumping off points that can be leveraged by anyone motivated to adopt the premise, adapt it to conditions on the ground, & experiment.