How to Avoid a Bad Project

Do you ever feel out of control of your project?

Over the past 27 years, I have worked on over 500 large scale projects. Within these 500+ projects, I have taken an interest in listening to client’s and other project professional’s previous experiences about projects that have gone bad. In these conversations, we can learn from failures and plan for better success in the future. But to be quite honest, I will do anything I can to prevent a project that I am working on from “going bad”. With that being said, there are some things that are outside of my control. As much as I want the project to be successful—I do need the client to be in control of the right things.

There are a variety of reasons why projects go bad. Sometimes, it is the partners fault, sometimes the client’s, and sometimes there are situations that are completely out of everyone’s control.  I have had an active interest in how to build the right team environment so that all the members of the project know their roles.

Quite often, the client conveniently blames their project partner as the responsible party for the failure. However, from my experience I have seen clients invest themselves to the success of their project and make use of their project partner as an experienced consultant who can deliver their required—or desired project.  As the project expert, every project situation should be handled with the assistance of our experience for the purpose of efficient success.  I have listed some of the most common items that can lead to projects not going the way the client expected. With this list, the client can at last take more control of how their project turns out.

The key in each of these, is that when an issue is brought up “after the fact” it is too late for good communication. The project is well on its way to “bad”.

1.     Requirements –Client says, “But, we talked about having more features and functions in the system.”  “Consultant says, “Yes, but it wasn’t in the scope.”  To save arguments, make sure every requirement you expect is in the scope as a deliverable.  — regardless of how seemingly irrelevant. — Similar to building a house, this is your blueprint.

2.     Hours Billed – As much as we would like to police the client’s employees we really don’t have the authority.  The client should have someone in charge that can approve requests.  The project consultant’s job is to take the client’s requests and complete them. Without an internal monitor, even small tasks add up.  We can avoid invoice arguments about scope creep if the client identifies who has clear authority to authorize service requests.

3.     Scope Creep – Avoid asking for new things.  Getting a new system is exciting. It invites brainstorming and to imagine the new possibilities. It seems like an ideal time to make changes as it is now easier than your previous system allowed. However, this necessary “shopping for solutions” mindset often leads to many impulse requests during the project.  Thus, “scope creep”, potential delays and increased costs.  A client can take control of this situation by designating an internal project manager who should manage these requests and decide if they are necessary.

4.     “I can do that piece” – Clients will always want to reduce unnecessary costs. We appreciate that, and are sensitive to your budget.  In every project we do, the client has wanted to take on a part of it.  However, once they do that, not only have they become part of the team, they will need to adjust their workload to handle the new responsibilities..  Too often , clients get involved but can’t deliver their part of the project on time because of other business factors.  This leads to increased scope and potential delays in the project.  My advice to the client is to be sensitive to what you can and cannot take on.

5.     “Google is our consultant” – As much as we would like the instant and free advice that can be found on Google. Google is not a professional consultant.  Google is one tool that clients and partners use. However, Google hasn’t reached the level of offering a listening ear and providing the personal solution with a vested interest in the success. Large scale solutions require combining many answers, and experience into an efficient custom fit solution.  –Trust the consultant and be collaborative.  Most of us have at least 10 years of experience and you just can’t catch up that fast by searching google.

6.     Talk to each other –Large scale projects are not turn-key systems.  Talk to each other as much as possible.  Don’t mistake “no news is good news”.  We could be assigned to communicate with an employee, and are waiting for a response.  The client’s employee– for unknown reasons– did not follow through on responding with the required feedback. The client should take control of their investment by demanding at least short weekly status meetings or even call multiple times during the week.  This is a big investment and it is understandable that you wouldn’t take it lightly.  If you were building a house it is advisable to visit it a couple of times a week to see the progress.  A large scale project is no different.

7.     Be Direct – While something can still be done about it, don’t be afraid to call us out on anything that you think isn’t right, or concerns about if it is going the right way, or it is not meeting your expectations.  Our experience, makes thick skinned enough to hear your concerns, while still being sensitive to them– most of us won’t be offended.  We would rather have that conversation sooner rather than later.   A better relationship is when both members still have an opportunity to communicate towards a mutual understanding and agreement.

I can’t speak for other partners, but I look at every engagement as a long term relationship opportunity.  I want every project to be successful and look to a continued future relationship. As project partners, we should be able “to live with each other”.

Want more advice on how to not let your project “go bad” or “stray away” from the success of a good implementation? Contact KTL Solutions at 301.360.0001.


Tim is the founder and president of KTL Solutions, Inc. He provides high-level guidance to our clients in order to help them better use technology within their organizations. He has an ability to understand the issue and provide a solution that best fits the client’s needs. When implementing solutions, his focus is to utilize off the shelf solutions first and customizations second.

Tim is a Certified Public Accountant (CPA) and has over 17 years of Microsoft Business Solutions software implementation and development experience. He started implementing Dynamics in 1987 in the early years of Great Plains on the Apple Macintosh. His responsibilities include mentoring new developers, teaching accounting principles and processes to developers, and leading the development and design of custom solutions. Tim oversees KTL’s Microsoft Business Solutions vertical market business.


Share this post

Related Posts

Checking Your CMMC Progress

Written by Alec Toloczko With Cybersecurity Maturity Model Certification (CMMC) requirements on the horizon, it’s crucial for organizations handling Controlled Unclassified Information (CUI) to adhere

Read More »