This week, I was asked where I saw the pain points of IT in innovation processes and how the IT component changes innovation processes. My answer was that IT is often not the primary point of failure, although management often perceives it to be so.
When I’m involved in projects, I always start by clarifying the business need. Building or procuring technology is pointless if you don’t know what problem you are solving.
I want to have a clear understanding of how the innovation’s outcome will impact the end-customer (for example, the user flow in an app), but also how this product will recoup its development costs (i.e., the business model and therefore the business case). The requirements follow from this, and only then can you properly design the technology.
What I have seen go wrong in many projects is that the business side mainly consists of general statements and vague slides, creating ample room for confusion where people use the same words to mean completely different things.
If you only realize there was ambiguity once the developers deliver their part, you’re already very late, and suddenly everything has to be adjusted even though an entire product has already been built. Meanwhile, a lot of people are working on the project, so every day costs a lot of money.
Scrum was invented as a way for IT professionals to deal with the vagueness and fickleness of the business. But that only works if you’re incrementally improving an existing product, not if you’re developing something completely new.
In large innovation projects, the technical team first does a lot of groundwork, regardless of whether the technical element is computers or something else. Only then can you deliver things that the outside world can see and see that things are going wrong.
In a bad environment, people point fingers at the techies because they didn’t know what was meant. Yeah, right!
If you’re looking for an inspiring story for your project kickoff, LET’S TALK!
