Is Your Latest Project only 'Good Enough'?

I don’t understand,” a friend of mine lamented during a recent conversation. “It is 2017, 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 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 a Project is Worth Doing, It's Worth Doing Well.

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 subpar 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 going 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 companies must focus on business outcomes, 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".

Read More

About the Author

As Trilix’s primary technical leader, Randy ensures all engagements and solutions are of the highest quality—working with clients from presales through execution to make certain they have business-outcome improvement based engagements.

He has more than 20 years of experience driving vision and intelligently leveraging solutions in technology, having previously worked as a Client Engagement Partner at Atrion, Director of Development at multiple healthcare software vendors, and IT Director at Lifespan, among other roles. He is a Certified Scrum Master and received his Master of Science, Information Technology, from Carnegie Mellon University (while working full-time and still finding time to spend with his wife and two kids!).