top of page

How Lacking Clarity Robs Us Of Millions in the Technology Sector

Lacking clarity at all levels in organizations today costs us both fortune and happiness. With all of the changes we have going on, it is even more important that people learn to develop clarity for each other within all levels of the organization.

Our approach should be to collaborate with our clients and colleagues to help untangle the communication knots, instead of funneling them through, hoping that they will get caught up in someone else’s funnel. The truth is that the further down the rope the knot moves, the more tangled up it gets, and the whole organization ends up suffering for it.

Here is a story of how it can happen in the Information Technology industry, what it costs, and how we can work together to ensure the best possible outcome for the organization.

The Beginning

It all starts with a team of executives from ABC Org who request that a specialized tech company, Tech1, creates a system solution for them. ABC Org wants this system to allow them to level some of their processes and deliver more services to their clients on a single interface. They rely mostly on Tech1’s acclaimed expertise to deliver the solution to them. Tech1 happily agrees to do this and reassures them of their commitment to the goal.

On Tech1’s side, it quickly becomes obvious that there is a lack of business and technical specifications regarding what ABC Org is actually requesting. ABC Org is relying on the Tech1 expertise without providing clear enough specifications of what they actually want. The managers gather their teams and ask them to create a solution similar to what had been done previously for one of ABC Org’s competitors. Carl, the Project Manager, and Mia, the Chief Analyst, both request to meet with an analyst or a leader on ABC Org’s side for some further clarification. Their questions are vaguely answered, leaving them without any real answers at all.

ABC Org’s team insists and believes that Tech1 are the experts and that they should help or guide them. They trust Tech1 to deliver for they are renowned experts in the market. So Carl and Mia decide that it would be easier to base the solution design on a solution that was previously developed for a competitor, as ABC Org lacks clarity about exactly what they require in order to launch the project. Carl and Mia promise to update ABC Org regularly.

Confusion breeds more confusion

Design and development proceed and the teams do their best with what they have. After the unit test, the product is sent to the Test Team. Philip, the Test Leader, for several months, has been asking Mia for specific information about how to validate the solution. He was given the main idea, but does not have enough substantial information to effectively build any reliable test cases. He ends up, again, basing his solution on the competitor’s model.

He calls a meeting with the client to discuss how the project is going to be validated in the Acceptance Phase. It took several months, but Philipp finally had a meeting about the acceptance testing. He then officially requests ABC Org’s Acceptance Criteria which they will use to validate the solution. In fact, these criteria do not officially exist at ABC Org and have to be created. Sadly, it takes yet another month before ABC Org puts a team together, completes the work, and passes the information on to Phillip.

A part of the solution was developed in India, and was based on many of the previous solutions as well. After some initial complications, it was finally integrated successfully into the system.

By then, the software was ready for Acceptance Testing. The System Test was completed successfully at Tech1. The test data used was based on work done previously for a competitor.

But then, on ABC Org’s site, many issues arose when they ran the initial Acceptance Test:

  1. The acceptance environment was too limited to effectively test the system integration on ABC Org site.

  2. Some specific processes, approaches and tools used by ABC Org are different than those of their competitor, since the competitor’s model was used, this creates further problems.

  3. Some technical incompatibility issues are identified.

The Acceptance Test period ended up being extended for so long that, in order to save costs and hopefully the delivery, a decision was made to move the delivery to the production environment. They began to run the solution in a long pilot or pre-production before an official, live production.

The support team at Tech1 was preparing to support the solution in production using the same directive used to support ABC Org’s competitors, the model on which the solution is based. Now they must constantly update their support strategy with the input coming in from the test team to effectively support ABC Org. They have to wait to have more stable guidelines in place before training the team that will be supporting the solution once it goes live officially. In the meantime, they pass the task along to development and testing. The Results

Migrating to the production environment revealed the following:

  1. Integration Failures: The new system does not operate with some of ABC Org’s technical infrastructure in place as many technical components are not compatible with each other.

  2. Process Failures: Many of the processes used in the new system are different to those ABC Org uses to conduct their business.

  3. Communication failures: Some messaging interfaces are not compatible, or they need a new interface created.

  4. Branding Failures: Many of the terms used are not always coherent in the software. This is also true for the overall style flow and layout, which they are still working on in an attempt to improve. Still, it is classified as a low priority for the moment.

  5. External Conflicts: Tech1 ends up blaming ABC Org and ABC Org blames Tech1.

  6. Internal Conflicts: On the client’s side, the test team blames the analysts. The analysts blame the purchasing department and so on. On Tech1’s side, the support team blames the testing team, testing blames development, development blames the project manager, the project manager blames the client, and so on.

  7. Employee turnover and workforce disengagement: Both companies end up losing some great employees who choose to go elsewhere. Many employees are under a huge amount of stress at each site. They are overwhelmed and some eventually burn out. Others choose to slow down, work less, and eventually take a break. Many remain in place but are disengaged. Resentment and conflicts bring an enormous challenge to the employees in their daily working relationships.

The Bill We Share

The investment to solve this is as follows:

  1. New system analysis (infrastructure, requirements) and alignment

  2. New technical system investment

  3. New training investments

  4. New business process definition and analysis --> realignment

  5. New development and countless change implementation

  6. Branding review

  7. Better employee well-being programs to help improve context and focus

  8. Communication Improvement programs

  9. Countless costly management meetings and negotiations

  10. Delayed delivery (loss of revenue and/or clients and maybe loss of market position for client)

  11. Extended project timeline – ABC Org may not pay the entire bill. Even if they do, there are additional costs that weigh heavily on HR for their workforce issues. The organization is losing.

  12. Costly legal fees and further communication procedures

How can we prevent this in a sustainable manner?

This is a simplified story of what is happening in today’s organizations. Believe me – and some of you can attest to this – it gets even more complicated than that. It is not one person’s fault. It is the responsibility of each leader or manager to gain clarity. Every time a manager or a team leader passes down poor specifications, or even no specifications to implement, he/she contributes to the chaos. Every time clarity is lacking, the flow should be upward and not downward.

I don’t mean upward in a rebellious manner, but upward with a request for clarification. Clarification is achieved through the use of proper questioning, proposition, research and findings, and opportunities for mutual understanding.

Thankfully, we don’t have to communicate only via lengthy text. This is especially true in an international context, where we use English as a working language, even though it is not the mother tongue for everyone.

Clarification approaches should use all available media in order to bring clarity. Examples of this include drawings, flowcharts, pictures, text, words, numbers, sounds, gestures and in some cases, textures. Every leader and manager, whatever the level in the hierarchy, is concerned

It does not matter whether you are a project or program manager, CEO, CIO, lead buyer, department or unit manager, lead analyst, lead developer, lead support, lead tester, lead architect, communication leader, or lead infrastructure provider – clarification is our business. It is in everyone’s best interest for the business or organization.

The reality is that we are all leaders in our areas of expertise, and we work together to deliver solutions. We need to be transformational leaders for what we are accountable for. We should not work just to ease our load and shift the problem to someone else’s funnel. When we receive a knot in the rope, we should contribute to, or help untangling it.

This is not just for ourselves, but also for the people who hand it to us – perhaps they could not untangle it alone. We must also do our part for the one who we will hand it over to, as well as for our organization, our clients, and everyone that it may impact.

Remember, your impact as a leader is much wider than the size of your team or the tasks that you are accountable for. Be a transformational leader and be empowered and proud of all the positive impacts you are about to make!


bottom of page