The Path for Energy Transformation: Co-Creation

Despite our best efforts, when working with clients we have yet to find a crystal ball that reveals (and deconflicts!) all of our stakeholders’ requirements, wishes, and workflows so we can instantly create the right solution for their needs.

And yet, we’re still consistently able to identify and build the right solution time and time again.

How do we do that? The secret is actually quite simple: we don’t create something for our clients, we co-create with our clients.

You have to be careful not to confuse asking standard discovery questions with co-creation; where you work alongside as many stakeholders as necessary, treating them as if they are part of your team (because in truth—they are). End users, executives, subject matter experts, and regulatory bodies (etc.) wind up becoming more invested and involved in the project because they have a role to play throughout the entire creation process. That is co-creation in a nutshell.

Build It Right, Or Build It Again

Anyone who builds software for a living can attest to the fact that most projects don’t follow a straight path. The more you peel back the onion, the more surprises you’ll find. You start off with a plan, and then through a series of seemingly innocuous conversations, you end up tossing out a good chunk of it. As Mike Tyson once said, “Everyone has a plan until they get punched in the face”.

And while we hope that no one actually gets punched during one of our projects, it is those metaphorical unexpected punches that make it so critical to maintain an on-going working relationship with project stakeholders. These are the folks that live these processes, and a couple conversations during the discovery phase aren’t going to cut it. The information you need to learn from stakeholders will change and develop over time. If you only interview those people at the beginning, you’re putting a cap on a tremendous source of knowledge and adding risk to the project. It’s impossible to extract every potential use case that every user (including the people who won’t use your application directly but rely on its output) will have in just a small number of interactions.

Too many times have we been brought in to rescue a project where the previous attempt had followed all of the right motions, but had resulted in output that was unusable. And it is always because the stakeholders weren’t involved along the way. They had upfront conversations, they defined a set of requirements, they even had meetings during the project to discuss progress, but they weren’t involved in the evolution of the system itself.

When the users and stakeholders are continuously involved in the build, you’re much more likely to get things right the first time, sparing you from the pain (and cost) of doing repetitive work.

Co-Creation Yields Consistent Results

At Simple Thread, we owe a large portion of our success to this co-creation with our partners.

As we’ve discussed previously, trust is hard to build. When we show potential energy clients all the work we’ve done in their industry, and the results we’ve delivered for other clients, no matter how impressive it is, they all wonder the same thing: “Will I get results like these”?

When the results are linked to a pair of mutually invested parties who both believe in the tenants of co-creation, then the answer can be yes. Co-creation gives the client ownership in the results, which is exactly how it should be. You’re not left wondering if you’ll be happy after many long hours of development have been done leading up to the “big reveal”. But instead, your team is able to confidently move forward, because you’re deeply invested and involved in the process.

Timelines, Schedules, and Mandates (Oh My!)

Now, you may be thinking “But Justin, this sounds nice, but it’s going to be incredibly time consuming”. And to that I would simply say, “You’re right”!

Time constraints are the challenge that come up against co-creation the most. Working closely with clients is time consuming. When you ask for feedback, you don’t always get it immediately. The more people you have involved in a project, the more time you may spend waiting for input. Differing opinions and needs can also sometimes create lengthy discussions about the best path forward, which slow down progress.

I fully understand that time isn’t a luxury we can always afford.

Timelines, schedules, and mandates imposed upon our clients sometimes require a faster solution. Believe me, I get it. On the surface, speed always sounds great (especially in project proposals). But let’s not allow this short-term need (meeting a pending deadline, perhaps) to get in the way of long-term results. It’s been our experience that clients are very helpful in keeping a project on track—when—we set clear expectations so they understand how critical their role is. It is usually when clients don’t understand the importance of their role (because you weren’t informed) that they wind up causing inadvertent delays.

In the end, most folks are after a sustainable solution that produces real results. If the software doesn’t deliver that, then everyone wasted their time, no matter how fast it was delivered. That will send you back to the drawing board to fix overlooked or previously ignored issues at best. And at worst, it will result in a lot of work being thrown out the window.

So let’s be mindful of timeliness, but not at the expense of our clients’ long-term vision and purpose. Which sounds like a great place to pick this series back up next time.