Dragan Babic enables design.

Wicked problems

On founders self-funding projects, and how it affects the process.

We’ve done quite a few projects that were funded by the stakeholders themselves; I mean, projects that weren’t spinoffs of preexisting profitable businesses, but were literally funded by the founders’ personal capital. And we’re happy to do them, they are very interesting to work on as you get amazing involvement from everyone, they are dynamic, and interesting because they are exploratory by nature. People came to us with a budget and a task to explore a certain opportunity and see if there’s potential for business, what’s not to like? It’s almost too perfect in its naiveté.

And this is where it gets tricky.

The sheer fact that the founders’ personal capital is used to fund the project makes the team vs. stakeholders dynamic completely different. By default things are much more personal from the start.

Due to this level of personal involvement from the founders, there is a high chance for the project to suffer from any or all of the following:

  • issues with delegation of responsibility and problem ownership,
  • trust issues,
  • avoiding essential parts of the design process like testing or research,
  • inability to commit to a goal, direction, or process,
  • etc.

This is why when a project shows any or all of these signs, I call them wicked problems. It becomes impossible to make progress due to ever-changing scope or specification so you feel like you’re stuck on a treadmill, frustration levels are high, and there’s that ever present feeling of time passing by, and money being spent. A situation no one wants to be in, yet there we are.

How to avoid a wicked problem project

Considering it is your task to qualify the project, it is essential for your judgement call to make sure there are no red flags concerning a couple of key factors.

Financials

Make sure that the stakeholders are financially stable, that’s a given. People don’t handle things the same when they are burning 1% vs. 50%, or 90% of their savings. Ask how are they viewing the project; an investment? An expense?

The human factor

Obviously, we are not all the same, and we all handle stress differently. Try to find out how important this project is for the stakeholders. Is this something they are doing on the side without putting too much pressure on it, or are they considering it their big break, or God forbid their saving grace? How busy are they? Do they have a full time position somewhere, and how stressful is that job? Because that stress can and will spill over.

Experience

Are they maker types, or investor types? How entrepreneurial are they? How much experience they have in product design and management? Have they worked with designers before? All this will affect how much hand-holding you will need to do during the project, and it affects everything from your bottom line, to overall team atmosphere and relationships.

After you’ve gathered all the information you can, in order to make your call try to label the opportunity as high risk, or low risk.

An example of a high risk opportunity would be something that has to work out, otherwise there will be negative consequences to the stakeholders. If this is the case it’s a good idea to keep these projects on a “tight leash” so to speak, meaning insisting on a bigger advance payment, and a tighter billing schedule if you have any doubts in the health of the stakeholders’ financials.

low risk opportunity might be a research, exploratory project where any outcome is valuable to the stakeholders; i.e. if it’s a success it validates their assumption and they can pursue the venture, but if its a failure they can still appreciate learning about it so early in the process, so they limit their losses.

I hope this helps you avoid some complicated situations in the future.

Created
2018-11-07

What's this?

Dragan Babic is a design consultant enabling creatively challenged organizations to nurture design, and work with design professionals in productive ways.

You are reading his blog.