Stamp of Approval

Most ProjectWise users understand the difference between “customization” and “configuration”.  In short, the former generally refers to using the ProjectWise SDK to develop C++ programs that will alter existing or create new options in ProjectWise.  The latter uses nothing more than built-in processes to extend delivered ProjectWise functionality.  In my experience, most users fall into the configuration category; it is cleaner and easier to maintain a ProjectWise system, plus many users have neither the in-house expertise nor budget to modify code, relying only on ProjectWise out-of-the-box features.  In these instances, I will work with users to try and develop configuration that can achieve their desired result, so long as it is not a large administrative or end user burden.

One such challenge was a recent request to have an event-driven “stamp” placed across a drawing title block.  This is not a process that can be easily automated, but I began thinking that I could come close by using four core components of ProjectWise: a workflow, document attribute, Attribute Exchange and the new Rules Engine.

For those of you not familiar, the Rules Engine (introduced in the ProjectWise SELECTseries 4 .559 build) is a new ProjectWise Explorer extension that allow administrators to configure document processing events for each State in a Workflow.  When the Rules Engine is applied to a Workflow, it replaces the standard ProjectWise Explorer Change State commands (Next, Previous and Change) with user-defined operations.  A Rule can be defined to run a set of “Actions” that are configured to run in a specific, sequential, order.  The Action is a ProjectWise task that may be carried out on the document – such as setting an attribute value – before changing the document State.

Armed with this new idea, I worked with the user to develop a stamping process.  Their need was to clearly mark a PDF (or Plot) as PRELIMINARY or SUPERSEDED in their title block, automating the process as much as possible.  This user does not use ProjectWise Workflows, so I created a mock one, which contained only one state.  In this case, the name of the State (Approved) and Workflow (Stamp) is arbitrary since their usage is only to link to the Rules Engine.  Next, I added an attribute (Stamp) to their existing ProjectWise Environment.  The Stamp attribute does not require any special value settings, although it may later.  Therefore, the Stamp attribute starts out blank:

Stamp AttrTo ensure that only the Rules Engine updates this attribute, it is configured as “read only”.  Next, I created a MicroStation Tag Set and Tag (both named Stamp), with the tag itself placed in the drawing title block on a 45 degree angle in a light gray, block font.  Like that Stamp attribute, the Stamp Tag is blank to start.  I then created a corresponding ProjectWise Attribute Exchange Class Name and Attribute and “bound” it to the MicroStation Stamp tag.

With the configuration complete, I can start the stamp process.  First, the users highlight the drawing(s) that require the stamp, right-click and select Change State.  Since the Rules Engine is attached to my Stamp Workflow, the standard commands Next, Previous and Change are grayed out and replaced with my new Actions:

CaptureIf I select the “Stamp PRELIMINARY” option, I am presented with a confirmation dialog box:

Stamp ConfirmSelecting Yes automatically updates my Stamp document attribute to PRELIMINARY.

Stamp Attr - PRELIMWhen I open the MicroStation drawing, the Attribute Exchange process runs, placing the Stamp attribute across my title block as desired:

Stamp Attr Exch

Keep in mind that this simple process can be imbedded in a deeper, more complex Workflow strategy.  As with many other ProjectWise commands, there are several configuration notes for the Rules Engine that you need to be mindful of, including but not limited to:

Setting an Attribute:  There is a Rules Engine variable called SET_ATTR (1 of 8 variables) that will populate a ProjectWise Environment attribute automatically.  However, it can only populate Environment Attributes and not standard ProjectWise attributes such a Description.
Working with existing Workflows:  When you configure the Rules Engine, you identify what Workflow it will run on top of.  It will not affect any other Workflow in your datasource
Condition Checks:  Using the Rules Engine, it is possible to check on whether or not an attribute is populated before changing a document(s) to the next State in the Workflow.  However, it does not validate what is in the field.
Permissions: Although the Rules Engine can override or disable some standard ProjectWise commands such as New Version and the State Change commands, a user must have the relevant ProjectWise rights to carry out these actions.

Advertisements

“Would you like the can, sir?”

I still chuckle watching that scene in the movie “Up in the Air”, where Ryan Bingham travels across the United States as a businessman. I reference this movie often when asked by users what it is like being a Bentley ProjectWise Consultant which, by the way, is a far more rewarding career than firing people for a living. When I explain what it is we do, the reaction from users usually range from “I could never do that” to “Wow that is pretty cool!” The fact is I very much enjoy my work and, usually, the journey.

In short, a ProjectWise consultant is responsible for a wide range of primary activities, including training, new installations, upgrades and general counseling. However, it is never that straightforward. Each one of those topics has ancillary branches that require detailed collaboration with project managers, infrastructure personnel and, of course, the business/discipline community. In addition, we assist with providing demonstrations and assessments for potential users and system “health” checks for existing ones. The challenge, always, is to build the most effective ProjectWise environment that meets each users need. And no two are ever the same.

Looking beyond the work, I remember back when I was hired by Bentley, a colleague of mine told me that I would never travel anywhere “interesting”. After nearly 8 years with Bentley, I can say with certainty that has not been the case. Personally, I have had assignments near and far, from North American prairies, to major cities, to locations overseas. I have deployed ProjectWise in places unimaginable (Afghanistan) and exotic (Honolulu) and seemingly everywhere in between. Each location has its own charm and local stories (ask me sometime about my dinner in Erieau; that night in Amsterdam or my evening at the Inn at Chester Springs).

Some assignments call for a basic installation (is there really such a thing?), connecting users in one location, while others are more complex and require linking distributed teams. At least one common task in every assignment is to deliver training. For me, I would have to say that Administrator training is my least favorite activity, although I value it as one of my most critical. Something about talking 8 hours a day for 3 days does not appeal to me, yet I understand that proper training sets the foundation for every ProjectWise installation and cannot be marginalized. In fact, I recently joked with a user by twisting the expression “youth is wasted on the young” to “administrator training is wasted on a new user”. Of course that is not true, but there is merit to holding a ProjectWise Administration review after everyone has a clearer understanding of ProjectWise functionality and how it should be applied to their installation.

So how many assignments have I had? Well, let me start by saying I am a US citizen living in Canada as a “landed immigrant”. As a landed immigrant, I hold a Permanent Residency card, which renews every 5 years. As part of the renewal process, I am required to list all international trips. To make this easy on myself, when I started with Bentley I decided to track every trip (domestic and international) in Excel.  To date, I have had 177 assignments for 69 different users in 58 cities, averaging 120 hotel nights annually (and these numbers likely pale in comparison to some of my peers).  With one account, I was assigned as a “resident consultant”, meaning I essentially remained on site for 4-6 weeks for one project and up to 2-3 months for another.  During this time I have formed professional and personal relationships with so many users that it is impossible for me to list them all.  This is what I consider the most important aspect of my profession; the ability to connect with the end users, make them feel comfortable, gain their trust and respect and empower them with the knowledge required to build and maintain an effective system.

And while I may not agree with all the philosophies of Ryan Bingham, we are in alignment with at least one; always wear slip-on shoes!

What’s in a Name?

Hello and a belated Happy New Year!  Okay, so part of my New Year’s resolution was to post a blog a month.  It looks like I cut it a little too close.  Maybe I should officially change that to averaging a blog a month.  Ah, such is life as a ProjectWise consultant (hmmm, there is my next blog!)  Anyway, I digress.

I have had several requests over the last couple of months from users who are trying to establish a specific naming convention for documents being created in ProjectWise.  This is always a polarizing topic, spanning all verticals/disciplines.  ProjectWise does provide a mechanism to aide users with this process – albeit with a few kinks – called Document Coding (referred to as “code” for this post).

A code is simply a process that allows a user to uniquely name a document in ProjectWise, using a combination of Environment attribute fields separated by a character (or not).  While almost every organization can take advantage of a code, most will have different requirements.  Let’s take a look at a recent code I developed for one of my users:

DC_1

PW Attribute Tab

In this example, the user had 6 requirements for their document name/filename: Year, Job, Unit, Discipline, Index and serial number (Seq).  The first step is to create a ProjectWise environment, which contains an attribute for each required code field.  In addition, I created (among other attributes not related to the code) a Drawing Number and Activity Description field.

Each attribute can be setup using a variety of ProjectWise options.  For example, the Year and Job (number) are automatically populated from their ProjectWise Project ‘Property’.  The Unit field is a basic ProjectWise attribute ‘Pick list’, while the Discipline and Index fields use the slightly more complicated ‘Look Up table’ methodology.  A Look Up table provides a user the means to develop pick lists using tables created in ProjectWise Explorer.  This allows a user the ability to add options to the pick list without having access to either ProjectWise Administrator (rarely) or the ProjectWise database (never).

The Discipline and Index fields form a ‘cascading’ pick list from the Look Up table.  In short, the options available in the Index are directly related to the Discipline selected.  The Seq or Serial Number field will automatically select the next available sequential number.  The Drawing Number field is a ProjectWise attribute identified by the code as a ‘Placeholder’.  This placeholder stores the complete code string, which can be delineated by a character.

The user requirement for this code presented an extra challenge.  The Index field is a 2-digit code that represents some sort of document type within their organization.  When the code pick lists are finished, there will be dozens of Index numbers (01, 02, 03, etc.) for each of their approximately 2 dozen Disciplines/Departments.  Users do not know, just by looking at the Index number, what type of document ‘Activity’ it is.  So the Index field had to include both its index number and description.  However, the description could not be part of the document name/filename when created.  This was achieved by writing a SELECT query in the Index attribute field that stripped the Activity Description from the Index field and place it in the Activity Description field.

As you might expect, the code process comes with pros and cons.  The main con is a Document Code can be broken.  Therefore, when using a Document Code, take into account the following:

A Document Code uniquely names a document based on a ProjectWise environment:  Many users believe it uniquely names a document within the datasource.  Not true.
A ProjectWise environment can only have 1 document code assigned:  If you have separate requirements for multiple disciplines/groups, this may constitute the need for a separate environment.
The Advanced Wizard (1): Is the only mechanism that works with a Document Code.  If a user creates a document using ‘No Wizard’, the Document Code is ignored.
The Advanced Wizard (2): Ensure that the Document Properties screen in the wizard is disabled.  If it is not, a user can overwrite the name/filename created by the code.
The Advanced Wizard (3): If you enable the ‘Create Document’ or Completion’ screens  in your Advanced Wizard (which appear after the Document Code screen), the user can hit the ‘Back’ button, which will automatically enable the Document Properties page, even if it is disabled!
No Wizard: Use of this option bypasses the Document Code, even if the parent folder has the environment set.  Note that this is working as designed.  It provides flexibility to create multiple document types within the same environment.  For example, you might create a Document Code for use with CAD drawings only.  However, the same environment may be used for other types of documents.
The Attributes > Document Code command: Look at the snapshot above.  All of the code fields appear to be read only.  Perfect!  However, that is not possible for the attributes that are pick lists.  They are simply greyed out because they are attributes of the code, which appear as read-only on the Document Attribute Tab.  If a user uses this command, they could modify the code attributes.
The Excel Import/Export Tool: Care must be taken when importing documents that are associated to a code.  The Import tool does not read or validate these attributes.
Code Field Separators: There are several default characters that you can select from.  But did you know that if a character is not listed (for example, the ‘_’),  you can simply enter it as your deliminator?
Document Code Restrictions: Restricts users to a range of numbers when creating a document code. Three types of restrictions can be created: Allow, Forbid, or Reserve.

If some of these options frustrate you (as it does me from time to time), consider that having a Document Code in place is usually better then having no process at all!  Many of these issues can be avoided with proper internal ProjectWise training and good security practices.

ProjectWise Startup Q&A

I was recently asked to reply to a short list of questions from a new ProjectWise user in terms of what they can do now to prepare for and facilitate their implementation of ProjectWise.  Specifically, these questions centered on developing a ProjectWise folder structure and document metadata.  I thought that this information may have value to other new or perspective ProjectWise users, so I have reworded the Q&A’s slightly (so not to name names) and am sharing the results below.  Keep in mind that:

– You should use these questions (and answers) as a guide.  You may have different requirements.
– While the focus was on PW attribution, this is by no means a complete list.
– The use of the terms “metadata” and “attributes” refer to the same thing.

Q1 – Is there a requirement for a single folder hierarchy?
No requirement at all.  Setting a PW structure is a critical function – for a variety of reasons – and should not be taken lightly.  I use the analogy with new users that a PW datasource is essentially an “empty white board” and you are free to do as you please.  You could certainly mimic your exact structure in PW, as it exists in Windows.  Of course, that is almost always a bad idea.  This particular user has an existing Windows structure near 400,000 folders.  While ProjectWise can support that many (it can support way more folders than you would ever want to consider), many of their folders can, should (and looks like will be) replaced by configured PW document attributes.  Users should also consider the use of ProjectWise Projects and their associated attribution in a datasource hierarchy.   All of this is covered in PW Administrator training, but it is a lot to take in, so you should include some post-training consulting in this area with your Bentley PW consultant.

Q2 – Can virtual or dynamic folder views be based on user role or department?
No, not really.  Users can create their own ‘personal views’ in PW and then assign them to a folder (if permitted).  This method allows users to display  a different set of attributes in the main PW document window (for ease and quick reference) based on the folder/project they have highlighted.  Users also have the ability (again, if permitted) to setup their own Custom Folders.  Think of a Custom Folder as a ‘shortcut’ in PW.  This shortcut can provide, for example, an abbreviated path to CAD drawings, or a link to an internal or external URL.  Users can setup as many of their own personal Custom Folders as they want.  Administrators can also setup global Custom Folders, viewable by everyone.  Users can setup PW Saved Searches (that can have a specific PW view attached) for quickly locating information based on any combination of metadata.

Q3 – How are metadata values auto-populated or inherited?  Based on user ID; folder storage location; other?
First, understand that all PW attributes are stored in an ‘environment’.  In turn, an environment is set at a folder (or Project) and all documents in that folder will adhere to it.  The display of the attributes is controlled by an environment ‘interface’.  One early decision you will need to make is “do I need multiple environments, or multiple interfaces?”.

Metadata can be auto-populated, so to speak, upon document import.  The best means is through the PW Export/Import tool, which leverages Excel.  The documents themselves are placed in PW folders, via the import tool, either by Folder Name or Folder ID number.  The metadata is then ‘attached’ to each individual document.  This can even include the addition of attributes to documents that don’t have any now.  Keep in mind that the delivered Export/Import tool does not recognize PW Projects, only Folders.

Q4 – What is a good Design approach for a First Draft of my PW metadata?
I would develop a basic list of attributes that should be considered.  Review existing internal sites that may be used for collection or repository of metadata (SAP, for one example).  Also discuss attribute values with your  appropriate discipline leads.  Keep in mind that you are identifying attributes that will help users find, organize and provide ‘light’ reporting on PW documents and records.  Try to keep your list of attributes to a minimum and remember that there is power in using them in combination.

Develop pick lists for your attributes, which can be derived in several ways, some not covered in PW Administrator training.  When establishing attributes:

– Understand what datatype is required for each (char, numeric, date, etc.) and what you are trying to achieve with the attribute.  For example, does it need to be a ‘Required’ field?  ‘Read-only’?  Should it be triggered by the result of another attribute in ProjectWise?
– Be cognizant of the field length requirement of an attribute.
– Be aware of the information you are putting in PW.  For example, is there a need to store emails?  If so, there are special extraction considerations that need to be in place to effectively track attribution that is particular to an email (From/To/CC, etc.)
– Do you need to establish some sort of naming convention for your documents?  Is this a need on just some documents, like drawings?  In PW, a ‘naming template’ for your documents – called Document Code – is created within your PW environment, using the PW attributes.  If this is a requirement, I recommend reviewing this feature in depth with your Bentley PW consultant as there are many options and constraints.

Q5 – What is a typical validation approach?
I like to develop a UAT (User Acceptance Testing) plan with a small group of key managers and users to validate your information and work process.  Review in detail the results with your lead ProjectWise team, including IT/IS and Bentley and make the necessary changes before you move off into a Production environment.

I will close with these few thoughts.  I always maintain that any type of collaboration system works better if it a) includes ‘push’ from upper management and b) involves all the critical groups that will use ProjectWise.  Making everyone feel like part of a team instead of being isolated goes a long way to improve the PW implementation and the ‘user experience’.  Lastly, I always try to impress upon any new users my K.I.S.S theory…(Keep It So Simple)!!

Disabling MS Office Integration

A new feature delivered with the ProjectWise SELECTseries 4 Refresh is the ability to enable or disable ProjectWise integration within your MS Office applications.  In the past, you could only disable the integration by re-running the ProjectWise Explorer installer and deselect the iDesktop integration for specific MS Office  product(s).  With the Refresh, you can now do this with a click of a button from inside the MS Office application.

But, where is it?  I will use MS Word as an example.  Simply open Word from your workstation and select the ProjectWise tab on the pull down menu.  Here you will find the Integration button, which is either set to ‘Enable’ or ‘Disable’, depending on how ProjectWise Explorer was installed on your workstation.

Office ButtonIf the ProjectWise integration was enabled, simply click the Disable button.  No need to hit ‘Save’ in MS Office.  Further, this setting is remembered the next time you start MS Word.  Lastly, this button is not available (it is greyed out) when opening a MS Office document stored in ProjectWise.

Remember, this is only available with the ProjectWise SELECTseries 4 Refresh.  To determine if that’s the version you have installed, open ProjectWise Explorer and do a Help > About ProjectWise Explorer.  If the commercial release is 08.11.11.559, you are good to go!

How you doin’…..ProjectWise Training?

Delivering ProjectWise User Training can have a huge impact within any organization.  I explain to all new ProjectWise Administrators that in most instances, this is the initial exposure to ProjectWise your users will have and it can greatly affect their ‘ProjectWise Experience’.   User training is a critical facet of a solid ProjectWise implementation plan, so do not take this lightly.

There are several ways to deliver training.  The ProjectWise training offered by Bentley is entitled “ProjectWise V8i SELECTseries 4 User Essentials Training” and is billed as an 8 hour class.  More on that in a moment.  The course material is thorough and comes with its own dataset, making the delivery easy (well, easier, anyway).  However, I try to stress that to deliver an effective class, users are better off developing their own manual (guide, handout or any other noun you prefer) and exercises that contain actual screen shots of your interface, environment, workflows, document creation, etc.  This form of training is generally well received and helps ease the user transition from their current work process to ProjectWise.

Now, back to the 8 hour training class.   Speaking from personal experience, I believe that is too long and can be counterproductive by exposing users to several task that I feel should be more administrative, such has Scanning for Reference File attachments, creating Folders or defining security.  Further, covering every feature in ProjectWise Explorer can be overwhelming and unnecessary as few users use all ProjectWise Explorer options.  The better approach may be to split the User Essentials Training into two 4-hour segments: Basic and Advanced.  The latter portion can be covered later, when your user base is acclimated to ProjectWise.  Or, better still – and my preferred method – forgo the advanced training and spend the extra 4 hours on ProjectWise ‘Coaching’ with your consultant.  There is always something that can be reviewed!  Oh, and one BIG tip; spend more time in training on performing ProjectWise searches!

Lastly, consider who should deliver your ProjectWise Explorer training.  One suggestion is to have your Bentley ProjectWise Consultant deliver the initial User Essentials Training in a ‘Train the Trainer’ format.  That is the Consultant trains your ProjectWise Administrators and they, in turn, train your user groups.  The Train the Trainer concept allows you to fully vet your training material while learning delivery techniques by a certified ProjectWise trainer.

Customizing your Bentley Transmittal Portal

Anyone that is currently using Bentley Transmittal Services (BTS) has likely noticed the “customizable headline” notation on the BTS Portal log in page.  However, did you realize that it is quite simple to alter both the logo and verbiage to meet your needs?

To modify the Portal logo, simple replace the existing TransmittalsPortalLogo.png file located in the …Program Files\Bentley\Transmittals\portal\contents folder.  To change the “customizable headline”, edit the _Layout.cshtml document located in the …Program Files\Bentley\Transmittals\portal\views\shared\ folder.   Change the text line <span>Your text </span> class=”ClientHeader”>@View.Layout_CustomizableHeadline.