congerdesign / Pixabay

“I don’t understand,” a friend of mine lamented during a recent conversation. “It is 2018, why can’t it just work?” He was referring to systems issues that he was experiencing at work and how exasperated he was that problems couldn’t be fixed or features added. After discussing the situation more deeply, it became clear that what he was really bemoaning was the fact that the technology was only “good enough”—the two worst words to be associated with technology.

These complaints are not uncommon from business users—many of us have uttered them ourselves! Because the fact is that when it comes to meaningful application of technology, “good enough” is rarely good enough.

Do any of the following apply to failed technology projects you or your customers have experienced?

  • Projects are accelerated to “go live” sooner than anticipated—meaning problems are fixed only as they arise
  • In projects, “victory” is declared and the team moves on before workflows are optimized and problems are addressed
  • Business end user involvement is superficial at best because the technology team asserts they know what users need

There are often valid business reasons for accelerating project timelines. But should that be the case, decisions (usually tough ones) still need to be made. For example, would adding more resources to the project help? Is the team available and are there funds for that option?

If those are not options, what features can we put on hold until a later phase? As Philip Stanhope, 4th Earl of Chesterfield, stated, “Whatever is worth doing at all is worth doing well.” In other words, no reason to release more features in a sub par manner because of an artificially declared go live date.

Worse still is idea that significant problems discovered in the implementation phase can be ignored and addressed after go live. In most cases this is a recipe for never truly addressing those problems because the team will be occupied with new issues and training needs. It would be better to release limited functionality that the team knows works than push out more, yet faulty, features.

Declaring “victory” in the face of defeat is a well-worn tradition in many areas. If just saying something made it true, perhaps I will declare myself the Earl of Chesterfield and see if I can take residence in his castle! That would likely be met with as much success as declaring unwarranted project victory.

Much like the previous example, it would be better to release limited functionality that is known to work or revisiting expectations.

Finally, even the best technology team needs to involve the end users in discussions and planning for the system, whether it be configuring a commercially available solution or developing a custom application. Without the end user, it is difficult to develop a solution that addresses business needs, elicit solution buy-in and develop a shared definition of success.

It is for all these reasons that technology experts drive engagements based on business outcomes by leading with business analysis, discovery and goals identification. With this approach, planning becomes a shared exercise and the definition of success is clear. Anything less is a recipe for business user frustration and only “good enough.”