A title that could not be more humble, for an article that has two parts. In hindsight, I should have made it two articles, but hindsight is a fair-weather friend, and yours truly doesn’t mind long articles.
In the first part, I will sing a song of praise to the consultant in our industry. I hope that after reading part 1, you might see us in a different light.
The second part is a reminder for consultants. A reminder that whatever we do only makes sense if we do it right. If you are a consultant, and you want people to sing a song of praise about you, here are the rules.
Part I — Tinker, Tailor, Soldier, Spy
In January 2008, I started a new job at a small-ish company called Omniture as a consultant on what has become Adobe Analytics.
When I started, my colleague André Urban introduced me to “Fusion”, an implementation methodology based around “fundamentals”, a standardised set of “micro requirements”, complete with a pretty standardised documentation.
We would pick the right “fundamentals” as per the type of customer (e.g. retail, media, b2b, …), implement and configure Analytics accordingly, explain what we had done, very slightly customise the documentation, then send that over. Job jobbed.
The documentation had one chapter per fundamental. Those chapters were build a bit like an Adam Greco blog post[tm]: explanation of business angle, short explanation of technical background, then a list of specific settings to be used for implementation, followed by a sample report with some explanation about how to use it.
Using the documentation, an implementer would be able to implement, and an analyst would know how to get what they needed.
We used to think of the documentation as a “consultant on the shelf.”
A real consultant, though, can be much more than a reference.
In our projects, we are, or act as: wedding planners, cooks, servers, guests, product managers, product marketers, product documentation writers, support, trainers, driving instructors, project managers, and probably a bunch more.
When we start a new project, we often first have to find out where we are, what the customer needs, and how we best get there.
In this phase, we are listening, planning, subtly nudging. You might call us planners, maybe even therapists. We also document the plan. Sometimes, we have to sell it, effectively being product managers and product marketers in one. The plan almost always has custom elements, which we design, or architect, or simply cook up.
Then we get busy, creating things, configuring, guiding others who implement.
We are engineers at this stage, developers, end users of our Adobe applications, support and mentors for other developers (such as you!), testers and QA people. We often manage tasks, dependencies, and the work of other people, not to mention expectations.
Once we have built what has to be built, we slip back into working closely with our customer.
We show them what we built, again selling the plan, teaching, mentoring, but no longer on a technical level. We teach our customers how to drive, and — crucially — how best to use this car. Sometimes we help our customer spread the idea throughout their organisation.
These are a lot of different activities. I guess that Jarod would have been a really good consultant…
With so many aspects to the job, the individual doing it makes a huge difference! Fusion tried to limit the influence of personality, standardising some of the activities above.
From the point of view of the consulting org, standards make life a lot easier. The same goes for customers. Working with a standard solution is easier, too. And it is easier to find a car mechanic that can repair a VW than to find one that can repair a DeLorean.
Even when some of your requirements are crazy custom, having a standard base is a good idea.
Fusion worked well, I think. So, what happened to it?
What happened to “Fusion”?
You know what… I don’t know!
There have been a lot of efforts over the years to standardise the delivery, the documentation, the project, everything.
At the same time, Analytics has moved on (who would have foreseen all the incredible things you can do with Workspace, to cite just one example), the whole Experience Cloud has grown, integrations have come and gone, matured, morphed.
In a thread about whether you should go to Summit, Jenn Kunz had this to say:
I used to agree that it was more about networking (which does have value, sales aside), but these days, I feel like Adobe is iterating on their products so quickly that there are always a few sessions that are 100% worth the whole conference, if only to catch up on newer tool capabilities and best practices.
I think we were simply overwhelmed. Keeping something like Fusion up to date and relevant in the face of a massively changing and growing environment is quite a task.
So we scaled down.
We made Solution Design References and Tech Specs, some of them standardised, some of them not, both of them covering but a small part of the field.
Nobody knows whether development will slow down, but I expect it won’t anytime soon.
And that means that when it comes to us in the consulting trade, we have to carry it all. There are currently no standards.
And because that is really a lot to carry, let me add to the burden in part 2.
Part II — Do it right
If you think that all of the above is crazy, you’re probably not far off. There really is a lot to do. The hard part is to focus on doing what makes sense.
It’s extremely easy to get bogged down in the little things. Technical issues can be conquered with clever ideas. Quick requests can be dealt with quickly. Customer requests can override plans, and even common sense.
It is really tough, and really important, to do what makes sense when you are a consultant.
How do you know what makes sense?
There’s an operational aspect, and a “value” aspect.
Operationally, the imperative is to be accountable.
If you plan something, deliver it.
If you build something, validate it, and document the validation.
If you have dependencies, document them, especially when it’s 3rd-party dependencies. That includes technology as well as people.
All pretty obvious, and yet we keep showing customers kick-off decks that list goals or deliverables, and we often do not go back later to see whether we have actually done those.
This is purely work ethics versus the demands of everyday work.
Yes, it is hard, but we can do it! I know we can!
Focus on value
The other aspect — value — is bigger, I think.
When we were in the UK, I had a software called VDR running on an old PC. Over there, we had tons of channels via “Freeview” (or DVB-T), and VDR was perfect for watching and recording. As a family, we stopped watching TV in real time. We all preferred recordings and being able to pause, and to skip ads.
Now, in Switzerland, there are fewer channels, and there is only cable. I bought a new decoder and attached it to a Raspberry Pi. Unfortunately, the combination of decoder and VDR on a Raspi is somewhat unstable. I have to physically unplug both of them once or twice a week, otherwise TV won’t work.
Guess what happened?
We stopped watching TV altogether. Even the smaller kids, who quite enjoy watching cartoons on Saturday mornings (when they are miracoulosly able to get up at 7, or earlier), stopped trying. And before you think “D’uh, netflix is better anyway!”, we do not have netflix.
In our job, we see the same thing. Things that our customers do not understand, or do not trust, will go unused. Even if it is easy to use, looks good, and is rock solid, our customers will ignore it if they don’t see the value.
I have written about value in the past, it is the one thing that I think we need to work for: make things that add value to our customers.
It’s really quite hard to do that, to be honest, but it is so worth it.
How do we even know we’re on the right track?
In August, I wrote about Responsibility, and I mentioned KPI frameworks. They are one way to figure out the big picture, and to help figure out what is important.
Without a compass like that, you’re lost before you even start.
If you do have a big picture, and you do know what will really help your customer, you still have two opponents left to work against: daily grind, and sometimes your customer themselves.
Daily grind is a relentless opponent. It has infinite patience and infinite resources. It wants to wear you down, make you forget why you are doing this.
Recognising that is one way to defend yourself. Another is to find positive experiences outside the daily grind, be active in our community. Yet another is to see what your work does for your customer, refuel your energy from the successes you will see. There are many more.
We all know we’re up against daily grind, and we all have our coping mechanisms.
The other opponent is our customer. They are a tricky opponent, because they usually don’t do it on purpose.
But they do it:
- Deprioritise documentation
- Ask for quick fixes
- Tell us that a KPI framework can’t be done right now
- Insist on broad, shallow scope
- Resist efforts to concentrate on the important
- Act as a gateway, and therefore become a bottleneck
Our customers have their very own agenda, pressures, deadlines, ideas.
Because of those, what they tell us will not always be in their own best interest.
We, on the other hand, are external, and we are free from a lot of the internal stuff that our customers have to deal with. That means we can help them stay on the right path.
Actually, we should help them. Or even must help them. It is, I would wager, part of why they pay for us.
All of the above boils down to 5 rules.
Writing manifestos is somewhat out of fashion, I guess, but we must keep these 5 things I in mind as consultants.
- Everything we do must be tied to value!
- Everything we do must be finished!
- Everything we do must be shown & explained!
- Everything we do must be documented so customers can re-read and understand!
- All documentation must be aimed at business & technology people! Yes, we must document it twice
We should always do those things that bring value to our customers. Any other stuff is vanity, procrastination. Doing non-valuable things also leads to higher risk of cruft and confusion! Stay lean and clean, and relevant.
Whatever you do only exists once you finished it. Half-baked or half-ready solutions are not solutions!
And if you do not show and explain what you did, you might as well not have done it.
Finally, document everything you create! It is great to show and explain, but your customer will want to come back later and re-read.
I’d say that an undocumented feature is not a feature.
These are high standards, no doubt.
I’m the first to admit that I fail on 3 to 4 out of 5 on most of my projects.
But if you need something to work against in 2020, why not these goals?!