Kansas City ~~ Kansas City, Here I Come

The first Bentley LEARNing Conference of 2016 is upon us!  I will be in Kansas City Monday, March 21 through Wednesday, March 23, delivering the following two ProjectWise sessions (click HERE for the full agenda):

ProjectWise CONNECT Edition Overview: With the CONNECT Edition, ProjectWise evolves from an engineering work-in-progress system to comprehensive worksharing, supporting the entire project delivery lifecycle.   This lecture will review new and enhanced capabilities, including multi-organization file sharing with ProjectWise Project Sharing, contractual communications including transmittals, submittals and RFIs with ProjectWise Deliverables Management and more!

 ProjectWise File Plan Preferred Practices: How many times have users setup a ProjectWise datasource with large folder structures?  The lecture will review how to minimize the number of folders by using attribution and how users can effectively use ProjectWise Saved Searches (and templating saved searches) to filter for documents and generate a report.

When I am not in session, I will be at the ProjectWise table in the ‘Ask the Expert’ room.  Note that I am the only ProjectWise representative currently scheduled to attend this conference.  If you have any questions, please stop by and see me!

 

Advertisements

ProjectWise “Reduplication”

Many years ago in seemingly a past life, I was part of an IT department working as a MicroStation CAD Specialist.  I sat next to a Unix Support Analyst (yes, Unix!) and would often hear his user conversations.  Many times he would say, “can you reduplicate the problem?”  Part of me wanted to correct him; but the cynic in me let it go because it just sounded hilarious!  So in honor of a fond memory, let’s talk about “reduplicating” what I call ProjectWise “Infrastructure Environments” in an on premise ProjectWise implementation.

First, do not confuse an infrastructure environment with an attribute environment; they are completely different.  Rather, consider each infrastructure environment as a specific set of servers, services and functions available to a ProjectWise administrative team to use at specific intervals. Depending on your organization (and complexity of your ProjectWise installation), an infrastructure environment can be a set of (duplicated) ProjectWise servers that represent your Integration, Web or iCS for PDF servers.  Or the infrastructure environment can simply be a separate ProjectWise datasource.  All ProjectWise users will have at least one infrastructure environment: PROD (Production).  However, my belief is that every user should have at least two; TEST and PROD.  Some larger installations make the case for three and (rarely) four environments.  Let’s look at some examples of what each infrastructure environment can represent:

DEV – Used for the development of the system process.  Here you begin to lay the groundwork for how ProjectWise server modules interact, review redundancy plans and start to build the framework of your ProjectWise datasource (security, workflows, attribution, data migration, etc.).  ProjectWise Administrator training is also delivered using the DEV environment.  The DEV environment also comes in handy if you want to upgrade and evaluate a new version of ProjectWise without impacting production.

TEST – Like all Infrastructure Environments, TEST continues where DEV leaves off.  Often times this environment is much like a “proof of concept”, where you can run-through the system processes to ensure that server resources and scalability run as expected.  This is where you continue to build upon the ProjectWise work processes defined in DEV.

QA – Again, QA will be a continuation of TEST.  However, in this stage, you will introduce some combination of an expanded design/engineering user group to functionally test the practices that your ProjectWise team has put in place.  QA will also help measure your overall server performance and resources (RAM, server cores and processors, etc.).  At this point you should have a datasource(s) that closely resemble what Production will look like, have developed an adequate UAT (User Acceptance Testing) plan to review ProjectWise functionality and have started to review all your training requirements.

PROD – This will be your Production system.  In short, UAT has successfully completed, all required documents (CAD drawings, etc.) have been migrated to ProjectWise, documentation and user training is complete and backup and restore procedures are set.  You are ready to “go live”.

Your ProjectWise datasource – moreover, your ProjectWise database – starts in DEV and is transferred (exported/imported) to each environment as you move forward in the process.  Generally speaking, when you move to QA, you should have at least 90% of your datasource (folder structure, attributes, workflow, security, etc.) in place.

Of course, there will be instances where a certain business process may need to change at any point prior to “go live”; workflow states, folder structure or document attributes are typical examples of this.  Depending on the change, you may decide to update the earlier environments (or not).  For example, if you catch something in UAT, you may wish to update DEV and reevaluate how that affects the overall process, then move the datasource (database) forward again (DEV to TEST to QA).  Once you are ready to move to Production, you might also consider migrating your QA datasource back to DEV and TEST, meaning that upon “go live”, all four datasources are synced.

Say hello in New Orleans

So, it’s been a while since my last post (not sure if that is good or bad!).  I have been adjusting to my new role within Bentley as the ProjectWise Services Director for North America.  I find this position equally challenging as my previous one (ProjectWise Consultant), but for different reasons.  I do plan to start blogging again and, like before, my goal is to blog once a month. Next week is the Bentley LEARNing Conference in New Orleans, Louisiana.  If you are attending, please feel free to look me up.  I am delivering lectures on Monday, June 29 and again on Wednesday, July 1.  My sessions include a sneak peak into ProjectWise Deliverables Management and some thoughts on how to plan a successful ProjectWise deployment.  I will also spend some time in the “Ask the Expert” room and, of course, be sitting at the ProjectWise table at both “Social Dinners” on Monday and Wednesday night.  I look forward to seeing everyone!

What’s in your……Toolbox?

Happy New Year!  I wish everyone a healthy and successful 2015!

One of my ProjectWise resolutions for 2015 is, from time to time, spotlight a tool in the ProjectWise Toolkit.  For those users not aware, the ProjectWise Toolkit is essentially a collection of packaged deliverables the Bentley Solutions team has developed over the years to meet specific user needs.

This post will spotlight the new PW Notifications tool.

In short, PW Notifications allow Administrators to define a variety of reporting options for ProjectWise.  Once the reports are established, ProjectWise users can “subscribe” to them by selecting a ProjectWise Folder, Project or Saved Search.  The reports are delivered via email to the subscribing users.  Reports can be setup to run via a scheduling tool such as Windows Task Scheduler or, if needed, can be run on demand (manually).

Once PW Notifications is installed and configured, a pull down menu option will appear in ProjectWise Explorer, allowing users to subscribe or unsubscribe to a report.  ProjectWise Administrators also have the ability to subscribe to a report on behalf of other users setup within the PW Notification tool:

PWN_01

Each separate report is configured within an Excel spreadsheet (a sample is included with PW Notifications) and supports a “DaysBack” option that determines the reporting time span and a “ReportFilter” that filters the records defined in the time span:

PWN_03

The reports can include a variety of filters, most similar to the options in ProjectWise Audit trail:

Added File, Attribute Update, Changed Security, Changed State, Checked In, Checked Out, Copied, Copied Out, Created, Deleted, Distributed, Exported, Extracted, Freed, Going Out, Modified, Moved, Redlined, Removed File, Removed Final Status, Replace File, Set Final Status, Versioned and Viewed.

The report output is embedded in an email, with a corresponding Excel spreadsheet attached.  Here is an example report run daily on all documents checked out and checked in ProjectWise.  Note that the report includes a URN link to the document in ProjectWise:

PWN_02Installation and configuration of PW Notifications is fairly straightforward.  The tool also includes its own logging capability.  For addition information on this tool, including pricing, please contact your Bentley Account Manager.

Ex’cell’ Linking in ProjectWise

As many of you realize, you can link ProjectWise document attributes to either a Built In or Custom Microsoft Excel attribute.  However, what if you want to link that ProjectWise document attribute directly to an Excel Cell?  Unfortunately, this process only works in one direction; from Excel to ProjectWise.  If you would like to give it a try, you first need to setup the Microsoft Office Attribute Support Exchange Rules in ProjectWise (follow the ProjectWise delivered Help documentation).  From there, you need to setup a linked attribute in Excel.  The process for that is fairly straightforward:

Excel Setup
1. Rename a Cell to something meaningful.  For example rename cell “C2” to “Drawn_By”.
2. Open the Excel Advanced Properties option and click the Custom Tab
3. Match the Excel Custom Name to the ProjectWise Attribute Exchange Name
4. Next to Value field, enable “Link to content”.  This will change the “Value” option to “Source”
5. Select the Cell Name you renamed in Step 1 above
6. Click Add.  The new attribute should appear in the Excel Custom Properties page

Excel Attirbute 1Attribute Update
1. Change the text in your renamed Excel Cell
2. Open the Excel Document Properties > Advanced Properties dialog
3. Highlight your Custom attribute and click OK
4. Select the “Update ProjectWise” command in Excel
5. Return to ProjectWise Explorer and view the document attribute.  It should be updated with the new value.

As with many other ProjectWise commands, there are several configuration notes that you need to be mindful of, including but not limited to:

– This option only works going from Excel to ProjectWise :  Unfortunately, I have not been able to get this to work coming from ProjectWise.  You may be able to write a VB script to do this, however.

– Be mindful of the ProjectWise FREE command :  As with all ProjectWise Exchange Rules, going to ProjectWise (from Excel, Word, MicroStation, etc.) will automatically write the updated attributes to the database.  Therefore, if you happen to FREE the document afterwards, the new attributes are still set.

ProjectWise Versions…Sauce or Gravy?

Ah, Sauce or Gravy.  That question has some Italian families squabbling.  My parents always called it tomato sauce, yet I have friends whom were taught that it is gravy.  I always thought of gravy coming from meat?  Sorry, I digress again – yet I cannot help but be reminded of that analogy when I start talking about a ProjectWise version.  Early in my career (largely as a Plant design/drafter), a “version” more referred to “what MicroStation version do you have installed” or “what version of Microsoft Office is deployed” than “what is the version of that drawing”. In that instance, a drawing always had “revisions”. Semantics perhaps, but it can cause confusion. Since it is called a version in ProjectWise, I’ll stick with that…at least for this post.

When working with users, one early topic we discuss are their particular requirements with respect to drawings and versions. Is the need to keep a historical, electronic copy that is editable (MicroStation, AutoCAD)?  If so, there are special considerations needed when establishing a firm set of version rules.

The immediate and glaring concern is obvious if you understand how versioning works in ProjectWise. On the surface, it is very straightforward; simply right click on a document and select the option New > Version. The user is presented with a dialog box where, among a few other options, they can choose to enter their own version designation or simply let ProjectWise number it for them. Once the command is complete, ProjectWise will create a new document version, which is linked to its master and has the same Name, File Name and Description as its original. The type of document does not matter – CAD, MSWord, MSExcel – they are all treated similarly. And there in lies the problem. There is no out of the box process to version all MicroStation (or AutoCAD) reference files when you version a master CAD drawing.  If you only version the master, are you truly creating a “record set”?  No, because in the absence of a reference file version, the master is preserved, but the references will keep updating.

It might be nice if ProjectWise could detect any attached reference file and prompt the user to version them along with its master.  But even if ProjectWise could, what version designation would you give the reference files?  For example, if the master drawing is moving to version “B”, “Issued for Client Review”, would you automatically version all references files to “B”?  Maybe not because one or more of the reference files might be a deliverable document, requiring its own version “B”.

One solution could be to use a “major/minor” version designation for the master/reference drawings.  For example, after you version a master CAD drawing to “B”, a user could select the ProjectWise option Set > Show References and, when the dialog box opens, highlight all the displayed references files and create a new version using the designation “B.01”, indicating that the attached reference files were versioned to support the master “Issued for Client Review”.  However, this is a time consuming and frustrating process.

A better solution might be the use of the ProjectWise Rules Engine, which can handle automatic version control strings.  In this scenario, the Rules Engine supports the format XYY.ZZ where X = Prefix Letter, YY = Numerical Revision (Major) and ZZ = Numerical Version (Minor).  Further, the Rules Engine can run a condition check called REFS_VALID, which is used exclusively for CAD Files with hierarchical reference sets in ProjectWise. A defined document attribute will be checked against all Reference files attached in a set and if any of them contain the value defined in Rules Engine (e.g. Unapproved), the Condition will fail and a new version of the Master document is not created.  But this is also a time consuming process.

The best solution might simply be to have ProjectWise, at time of issue, automatically create a PDF via the i-model Composition Service.  In this scenario, your ProjectWise Administrator can create a iCS “job” that is triggered by a ProjectWise Saved Search (“All Issued Project Documents”, for example) and, using an InterPlot Organizer setting file,  properly rendition a PDF and place that PDF in a predetermined location in of ProjectWise.  In addition, the iCS job can map the ProjectWise document attributes set on the CAD drawing directly to the PDF.

As with many other ProjectWise commands, there are several configuration notes that you need to be mindful of, including but not limited to:

– Datasource Version Settings :  There are several to consider and, since these are datasource settings, they are enforced for every PW Project.

– Rules Engine Behavior :  Some ProjectWise commands (e.g. New Version) and datasource settings (e.g. Use numeric version strings) work differently if a Rules Engine is applied.