Does your system solve it? The product alone isn't enough!

THE PRODUCT ALONE DOESN'T SOLVE IT!

The system was delivered, but it didn't solve the problem...

As part of my work, I help companies roll out off-the-shelf systems or build their own systems for internal use.

From my experience with project management, I can tell you the product doesn't succeed on its own: it's only part of the solution! It's the product plus about three hundred other things that need to happen, and only then does it actually work. That's why you need to understand clearly what's required to make it happen.

What are people actually looking for?

Clients want to know what they need to buy or build to solve the problem.

The project manager works directly on building what makes it succeed. Together with the team, they need to say that, beyond the product, you also need this, this and this, the whole package, for it to actually work.

In systems, that means simply making the system available isn't enough. It also requires:

• João updates the customer contact record every day;
• Maria fills in the full registration details;
• Cleuza enters orders within the time window;
• The team teaches people how to use it (training);
• Support actually follows up (which is different from just "being available");
• The analyst watches what's working and what isn't;
• The PM works through resistance;
• Marketing communicates the change;

You need to understand the impact on people who aren't even directly involved with that product or project.

Multiple interests in the project

Deeply understanding what your product will actually solve is essential.

The problem is that what's expected isn't always made explicit, and worse, each person or group has their own needs. Here's an example of different interests within the same context:

• User: what matters is the green button that'll make it easier to access orders and integrate with the ERP.
• Payer: whoever's paying wants to know when and what return using that product will bring.
• Buyer: wants to know there won't be any gaps in delivering the contracted product.
• Operations: wants to know it won't be a hassle to keep running.
• Saboteur: wants to know what their life will look like once that product shows up.

These interests are part of your project, and knowing about them matters for everything to work out.

So what now?

Fortunately, there's no one-size-fits-all recipe for handling this, since every project is unique.

Things that can help:

1. Look at places where that product already works well and figure out why it's working.
2. Structure the scope considering not just the rollout, but also what's needed to make it actually work.
3. Bring in a change management framework, how about Prosci's ADKAR model.
4. Have conversations with good questions with the people involved and affected.
5. Understand it in loco (or have someone there) to know what's really happening in practice.
6. Look at each person involved in the process: what matters to them?

Look at the product! Look at your project! Does it really solve things on its own? What's needed to make it work?

Now, if your problem is getting the team to collaborate, this article will help you, check it out here!

Take care,