Providing value on Unicorn Projects

Most of my time in consulting is spent mentoring and enabling customers. We all know customers come in many different flavors, with various levels of proficiency. It’s rare to find a customer that is already self-sufficient, both technically and culturally (understands the devops/agile mentality). I had the chance to see such mythical creature, and it challenged me in ways I never even considered was possible.

How was I supposed to add value to the project when the customer knows just as much (and/or more) as I do, especially on the technology that I was specifically brought in to help with?

This required coming up with a new game plan. What worked in the past doesn’t apply here, nor would it provide any value. I knew my most important asset was my experience with other customers. I’ve had the luxury of seeing what works (or doesn’t) and where common pitfalls are. Sure, this unicorn project might magically overcome some of the hurdles that other customers commonly fall on, but it’s useful to identify and call out potential obstacles.

Identifying obstacles that are specific to this unicorn requires discovery. It’s not as easy as reading from a checklist of common pitfalls, although that certainly helps.

Diagramming

Diagramming is a great place to start. Translating what the customer is telling you into something visual is beneficial to both parties. It highlights gray areas where there isn’t a clear definition or process, so that we have a place to focus on. What makes sense to the customer is fuzzy to me as an outsider, so I ask questions so I can accurately diagram it. If the diagrams don’t make sense (or wasn’t neatly drawn with right-angles and non-overlapping lines), that’s usually an indication that there’s something else happening in there.

It’s also worth noting that the diagrams don’t need to be proper UML, or whatever diagramming language is popular these days. Draw stick figures with circles and squares, swimlanes, decision and fork nodes, and random dashed or dotted arrows. Just make sure it is clear to you and the customer.

A great free tool for this is draw.io, which is essentially the free Lucidchart.

Talking to developers

Talking to developers is another place to find value. Note the plural on developers because the entire team should be involved, and not just the Tech Lead. The developers working in the trenches see (and do) things that might not be ideal because of X reason. They may have workarounds in place in order to meet corporate policy compliance, or toolset limitations that make their development-lives difficult. They could be under tight release cycles, or are required to use antiquated change management tools, or long process-approval steps. There’s usually good feedback to gather from the developers who may be doing their best to run in quicksand. Getting honest feedback from developers takes time since building relationships and trust isn’t immediate. As a developer myself, I tend to promote a developer-first focused environment. Making things easy for the development teams makes it much easier to spread my propaganda agenda.

Goals settings

This might be obvious, but make a list of customer goals. It could be high-level at first, but continually add details to it so that they become tangible tasks. Once you have that list, add in some stretch goals that they might find useful. These could be introducing newer technology, or perhaps some Day 2 operational tasks that they could get a head start on. Focus on the main tasks first, but if your customer is the unicorn you think they are, they might be well within schedule to complete this with or without you. Those stretch goals are ways to demonstrate value that the customer has already defined as useful. This is especially beneficial to you as a consultant as it gives you a checklist of things to brush up your skills in. Create a POC or demo, and document all the pitfalls you run into so you can warn the customer about these things.

Identify pain points

This goes along with stretch goals, but if you can identify reoccurring pain points, take some time to see if you can do something to help. Whatever is causing them pain might not be directly related to the project, but if it’s something you could spend a few hours on each week, you could be setting something bigger in motion.