The company had a problem. Multiple file servers, one for each office location, meant there were multiple places a project could live. Organizing thousands of active projects was no easy task, especially if employees from multiple offices were working on the project. The structure for storage of these projects was hard to understand for the average employee, and they were the ones creating the folders. With no governance and lacking a full understanding of how to setup the folders and why, it was a mess. This is what I walked in on.
One of my first projects at the company was to address that. The Project Start Form (PSF) was a Word document inside the office templates. I used that as a base reference, and began creating a web application in VBScript. The accounting database, Sema4, was in an old FoxPro style database, and I used that to provide drop downs and checkboxes. I was able to very tightly control the user interface and make it as easy as possible. Not only that, once that Project Manager was identified, it was a lot like the finder selection in Vision, I would find the office of that employee and automate the folder creation process. I even created a shortcut in the employee’s home drive and saved a copy of the PSF data in the project folder. Once the tool was ready and tested, I took away the PSF office template and replaced it with a link to the intranet-based PSF.
Standardizing the project folders was critical because it helps reduce human error and the amount of time it takes to find a given project on the network, especially in work sharing scenarios.
Then we converted to Vision and I had to create a C# .NET, custom workflow using Vision’s API in order to create project folders. Same logic as before, except now the data was all under one roof on MS SQL Server 2005, just like the intranet already was. However, there were still problems with standardizing the folders. Employees were still creating their own folders, and they were not adhering to the standards. Some wanted to have a Client Name in portions of the structure, and some wanted to have the Project Name in there, some both. It was determined that creating the folder on the network when the Opportunity is created was rather than when the Project is created. Additionally, they wanted to be able to create the folders in multiple offices rather than just the Project Manager’s office. By making those changes, we have almost eliminated employees creating their own folders: I even have people call me when Vision failed to create the folder!
However, we still had those that wanted client and/or project names in the folder structure. And data archive employees were falling behind. And our backups are running until noon. And there were copies and versions and large photos and videos polluting our active data. Something needed to be done. So, I gave it some thought and drafted a document. I had the Director of Information Technology and the CEO approve it before I spoke to the Leadership Team to let them know I was going to move forward. I was going to form a committee that would discuss the current folder structure, how to improve it, decide if client and/or project names were going to be included, and then lock it down so that no one could change what Vision had created. Vision would then have a primary key on the network and could always locate a project folder, no matter where it is. If that is the case, I can use more code to find and compress large photos, move videos to a non-production location, automatically move retired projects to archive, clean up folders from lost Opportunities, and, in general, keep our production data lean. As these automated processes occur, I can also reach back into Vision and find the project stakeholders and send them digest updates on what automation had done to the project folders and files.
That is where we are now. The committee meets to discuss until we have a ratified plan of action, which then goes back to the Leadership Team for approval. After that, time to code (one of my favorite duties!).