Andrews Engineering, Inc. had converted from Sema4 to Vision 2 years prior to them calling me.


Sema4 didn’t handle the project work breakdown structure as well as Vision does, and consequently, a lot of companies were converted incorrectly, with a mix of tasks and labor codes at the WBS3 (task) level.

In Andrews’ case, this resulted in having projects with long, confusing task codes under each phase, where each list was a mix of labor codes and deliverables.  Because the milestones and deliverables list were mixed together, it was necessary to have over 300 standard task codes to deal with each possible combination of the two.

The issues created by this merging of the two separate entity lists were as follows:

1. Entering time against projects was confusing at best and resulted in extensive time sheet entry errors and thus pre-bill changes

2. The logical budgeting and estimate for clients had to be translated to fit this mixed architecture resulting in budgeted amounts for things like “word processing/admin” and “client conference/phone calls”.

3. It was not possible to produce meaningful comparison reports (actuals to budgets) from Vision

4. Producing meaningful invoices in Vision required extensive custom invoice templates to meet client project format requirements


In order to distill the true work breakdown structure and standard labor codes from this list, it was necessary to do 4 things (in summary):

1. Define the difference between a labor code and a WBS element

2. Educate management and staff on the difference between the two concepts

3. Develop a method for translating existing project data into the proper division of work breakdown structure and standard labor codes

4. Convert projects using standard built in Vision tools (like key conversion), custom scripts, and a custom app developed for the purpose.

The result was a successful conversion of historical projects from the old, confusing structure (which made heads explode as people attempted to enter time against 30 to 40 redundant and confusing task codes for any phase of the project), to a new, simple and logical structure.

I also modified their invoices to show both staff type (labor category) and labor code on the invoice… this way they make use of all work breakdown structure elements to show their clients what they are doing on projects.

RESULTS(some images, samples):1. Define the difference between a labor code and a WBS element:
Their old task code list looked like this (click on the image to see full size).
Keep in mind that this is a list of items to be used for WBS3, when in fact it is a combination of activity codes (read labor codes) and milestones/deliverables (read work breakdown structure).

I have found that often when a conversion is done from FMS to Vision, the database often looks like this… these are also often called billing groups.

There are at leat 4 main issues with this long list:

1. Hard or impossible to manage (there are 320+ items)

2. Hard or impossible to decide which ones to select when setting up a project so often times the person setting it up merely selects all of them, which makes for excessively complex work breakdown structure on a project

3. Impossible for employees to figure out where to put their time when they are often in a hurry to leave for the day and filling out their timesheet… so they put their time “wherever.”

4. If you ever want to look deeper at the data and figure out why you went over budget on something… it’s almost impossible because of two issues above.

One example of an item that is a combination of labor code and WBS item is this:

Design/Calculations:  321 Gas System


Inspection: 426 Initial Waste Placement

In order to truly restructure this list and the way they do business, one has to separate out the activities from the milestones and deliverables.

2. Educate management and staff on the difference between the two concepts
The best way to “educate” management and staff on the difference, and show them how it would work, was to separate out the lists for them… and develop a new “activity code” or labor code list, as well as develop a new method for establishing work break down structure, and essentially convert some projects over.
Here is their new list of activity codes (labor codes)Notice that this list is very short, designed for selecting “what I was doing” when filling out a time sheet.

It is the combination of the Work Breakdown Structure (WBS) and this list of activity codes (labor codes) that fully describe a time sheet entry.

Here is the result… a project with its old “WBS” side by side with its new WBS after being converted.Notice how the new WBS actually represents the actual steps one would go through to complete the work. Notice how things like “document preparation/assembly” and “client meeting” are now in the activity codes list where they belong, and only milestones and deliverables are in the new Work Breakdown Structure.

Note: There are two WBS elements in the new project structure that don’t actually belong there… they are “Admin” and “Project Management”. These are really activity codes, but because of the existing timesheet entries with those types of activities, we had to include those in the new WBS on existing projects. It would have been “possible” but logistically impossible to separate out each timesheet entry to assign it to a new WBS element based on comments in time sheets.

Here is a snapshot of the Microsoft Access application I developed to solve the project conversion problem.This allows the user to:

1. analyse the existing project WBS

2. establish a new WBS for that same project

3. assign activity codes (labor codes) to each old WBS element

4… and convert the project entirely, including old invoices and all transactional data with a click of a button.

Note, it took about 8 weeks to develop this application from scratch with all associated scripts.


If you are suffering from a “bad implementation” of Deltek Vision, it is possibly to repair it or clean it up in a lot of cases.  It often can take weeks or even months to get the job done, but the end result of having a streamlined organization and data that actually makes sense can make a huge difference in operations.

My client in this case is currently stuck in the “project conversion” part of this project. They are undergoing some organizational changes at the management level, and have been unable to undertake the work necessary to convert their projects, even though they now have excellent tools to do so. The fact is, when you are looking at a project that has been ongoing for several years, and are trying to establish a new paradigm for managing that project at the granular level, it can be quite a daunting task, especially for project managers and staff who have been “doing it this way” for years and years.