The importance of a consistent naming convention and structuring your output cannot be overstated. As someone who has worked as a packager on numerous projects, I have seen firsthand how poorly structured output can lead to inefficiencies, delays, and confusion. While every project may have its own unique approach to working, it is important to ensure that there is some level of consistency and standardization in the way output is organized and named. In my experience, even large projects can suffer from disorganized output. I have seen situations where files and folders are scattered haphazardly, with no clear structure or logic. This may work for small teams with just a few packages to handle, but it quickly becomes unmanageable as the scope of the project grows.

The first fix to this problem is to create a template package folder with subfolders for everything that belongs to the package, such as documents, source files, project files, and the final package folder. When creating a new package, simply copy the template folder and use a consistent naming convention for each subfolder and file. This makes it easier to find the files you need, and also ensures that all team members are on the same page when it comes to naming conventions.

The second fix is to use the naming convention consistently throughout all related systems and processes. This means using it (whole or at least partly) to create the active directory groups, create distribution system entries, create ITSM entries, create CMDB entries, and so forth. By doing this, it becomes much easier to find relationships between the various systems and processes involved in the project. Many companies create entries in numerous systems, but fail to understand the relationships between them. This can make it difficult to clean up when packages reach end-of-life status or find the source quickly when questions arise.

In summary, a consistent naming convention and structured output can help to streamline workflows, reduce confusion and errors, and make it easier to manage packages and related systems. By taking the time to establish these practices at the outset of a project, teams can avoid many of the headaches that come with poorly organized output.