You went live. Congratulations. Nobody wants to use it.

The great day has finally come. It has been a wild ride for the last 2–3 years, and now someone will finally start using this solution. Real-life users will log in and start creating customers, opportunities and quotes.

The IT Director pushes the button and… after a week, further development is almost impossible due to the number of tickets coming in. The system is so hard to navigate that users are unable to use it, even though they have had training. Training is not a substitute for usable software. Waiting times are so significant that, while waiting for assetization, users can go for a one-hour lunch and come back only to find that the process still has not finished.

So, after a month, sales reps dust off their Excel sheets and start using them as a CPQ, CRM and whatever else this powerful tool and their imagination will allow.

Here, I would just like to mention that Excel is still the source of truth for companies worldwide, and as powerful as it is, it is not a CRM.

But let’s go back to the perspective of the IT Director, who is currently in quite an uncomfortable position. He has just launched a new solution and is already being asked to present a recovery plan. Definitely not a position you want to find yourself in.

This article will be the beginning of a series in which I will elaborate a little more on the sources of this kind of situation, because it is a multi-layer cake of bad decisions, mixed with the icing of poor practices and the wrong implementation partner as the cherry on top.

Today, I wanted to elaborate a little bit on what are the options that our IT Director has.

The board is quite unhappy with what is happening.

The IT Director’s current implementation partner is trying to deflect all of the issues by saying:

“That is exactly aligned with the requirements, and you accepted all of the User Stories.” The question that you wanted to ask is “Where did we state that the system is supposed to be unusable?”The discovery phase, translating requirements into user stories, and understanding why accepted user stories do not necessarily mean that the system will work as intended deserve a separate article. So I strongly recommend following our blog for the next part of the series.

In practice, the IT Director has several options. When trust in the existing delivery setup has collapsed, two are particularly common:

1. The first is to try to resolve this with internal resources: prove that the implementation partner is not right, identify bad practices and other issues in the solution, and determine what actually went wrong. But then someone will still have to repair it.
   On top of that, having enough internal resources to continue further development, fix the bugs, and conduct an audit at the same time is rarely a realistic possibility.
2. The second way is to hire a company that can come in, check the solution, and prepare an evidence-based assessment showing what is not working, why it happening, how severe the impact is, and what needs to be done to recover the solution; what the gaps are, which good practices were or were not followed, where the quality of the code is below an acceptable level, and so on. Finally, providing a clear remediation roadmap.

As I mentioned above, every implementation has many layers, at Craftware, we know how to inspect them layer by layer to get to the sources of the problems.

That might be the question after I tell you how long this cake inspection takes.

But you can take this as a given, because it is not our first rodeo.

As an example, I can mention our last major assessment, which was done for a large telecommunications company. It was a solution that had been developed over the previous five years, with a tremendous amount of customization. But with a proper plan, industry knowledge, and a handful of very experienced people, one month is more than enough.

At this point, I’m stepping out of the IT Director’s perspective for a moment and talking about our own team.

Here, I would like to stop for a second and tell you a little more about our employees.

The strength and knowledge of every organization is measured by a combination of the skills, experience, and knowledge of its employees. One of the experts who was a vital part of our last assessment was Grzegorz Popardowski, or, as he likes to say:

“No one outside of Poland can pronounce Grzegorz, so just call me Greg.”

Who is that guy, you might ask?

He has 10+ years of experience in telecom and Salesforce transformations, including 5+ years in architecture leadership. He took over a failing Communications Cloud CPQ program for a global Tier 1 carrier, stabilised delivery, protected the budget, and rebuilt client trust.

Grzegorz also played a key role in the Lead-to-Cash transformation for Telia Carrier and led backend architecture for the My Carrier Portal, exposing 180+ Salesforce APIs and integrating live product catalogue validation and CPQ across Salesforce and Heroku.

He specialises in high-risk programs, complex integrations and business-to-IT alignment in live telecom environments.

I’m writing this here not just to brag, “Look, we have experienced people.” but to underline one very important thing: these assessments and successful projects are not just about technical knowledge. They require a combination of industry, technical, and business knowledge.

That is why we can do this kind of engagement in a matter of a month.

Does it mean that we are experienced only in telecommunications?

Quite the opposite. That is just one of the branches, not the whole tree.

Apart from Greg, the team consisted of a Technical Architect / Expert Developer, an Expert Consultant and a Delivery Manager. Those guys will remain anonymous for now. I will tell you more about them in the next episodes.

The role of the Technical Architect / Developer is quite obvious, but also crucial. That is the person going down to the bottom layers, and it is not an easy task.

Reverse engineering, which is required to backtrack actual system behaviour, dependencies, assumptions, coupling, and side effects, is a highly complex task that requires a lot of experience.

The Expert Consultant had to do reverse engineering as well, covering all of the declarative tools and Salesforce features through which some of the functionalities were implemented.

Last but not least, who can give you better feedback on project governance than an experienced Delivery Manager with delivery governance experience?

The answer is: no one.

That is why a very skilled DM was also part of this engagement and contributed a lot to the report. He is the one for whom noticing even the slightest details that can postpone, jeopardize, or lower the quality of an implementation is bread and butter.

Yes.

And as far as I’m concerned, I do not know any other or better way to properly assess something. If you do, let me know.

Of course, we can read the documentation, if it exists. We can read the code, and of course we can go through demos and other recordings.

Nevertheless, that will not replace human interaction.

To make the process as smooth as possible for the customer, we divide the engagement into several stages.

In general, we have a couple of main stages:

1. Preparation and intro
   We gather all of the required access, documentation, and any other source of knowledge that we can get. We analyse it to prepare ourselves for the next step.
2. 2–3 days of on-site workshops
   For distressed programmes, we prefer to start on-site. It is simply the fastest way to uncover conflicting assumptions, hidden process exceptions and the kind of knowledge that rarely makes it into documentation.
   They give us the ability to gather the necessary knowledge, ask all of the questions and trigger discussions along the way. This also gives us what we need to move to the next stage.
3. Assessment
   We close ourselves in our offices for the next three weeks to prepare the assessment.
   During that time, we analyse, search, and document every finding and prepare the documentation supporting all of it, which we then present.
4. Summary and next steps
   The final stage is the Summary and Next Steps meeting, which we also like to conduct on-site.

We like to meet people in person. I know, we are a little bit weird.
It is the best time to summarise everything we found and trigger a discussion about what can be done next.

And that will be all for today’s episode of “How I Met Your Unsuccessful Implementation.”

In the next episode, I will describe in more detail what exactly we do during the assessment and how we proceed to the next steps.

For everyone who lasted until the end of this article, I wish you a great day and a tasty coffee.