Avoid these 5 project red flags

As a NAV developer for the last 6 years, I have seen great projects and those that weren’t so great. Over time I have gotten better at identifying the red flags that point to development challenges ahead. While some of these red flags are show stoppers, others are indications that we need to spend a little more time defining specifications or identifying the business need before we jump into code mode:

  1. Flowchart is either missing or resembles a spaghetti bowl. If the process cannot be explained clearly, it means there is no true process. Without a process, there is nothing to automate. Everyone involved in the activities should be clear on any steps involved, their order, and ultimately their business purpose.

  2. Modification lacks detail or purpose. Project stakeholders must be able to clearly articulate the business need so the  developer can craft a solution that meets it. Poorly designed modification projects often turn out to be band aids or workarounds for a fundamental business problem.   Projects that don’t make sense on paper won’t make sense in application either.

  3. Work instructions are too detailed or technical. In order to program properly, a developer needs to understand your business pain points. For a variety of reasons many projects instead arrive with very specific technical instructions on what needs to be done. While we appreciate your desire to communicate technical information, leave that to us. Your job is to make sure we understand what you are trying to accomplish and why it is important to the business.

  4. Project relies heavily on automated emails. Automated emails are awesome. However, they are not a magic bullet that eliminates the need for having a process. They are merely a way to communicate progress against a previously defined set of rules. If  data is readily available and no one is using it, why would automatic emails make the data suddenly relevant?  Have you ever directed automated emails to a folder so that they didn’t clutter up your inbox? First establish a solid process, and only then enhance it with automated emails.

  5. Project requester doesn’t understand the current state. When the project requester is unfamiliar with the system and how the company uses it now, it casts doubt on any information provided for the project. You cannot (and should not) charter a new path without surveying the terrain and understanding why the existing paths weren’t sufficient.  To ensure project success, you must do your homework or hand it off to a person closer to the situation.