Starting a new business

I am starting a new business for the PM community... PlanFurther.com

More details to follow...

Mentoring PMs

I found a great post on Linked In from Erika Flora dealing with local PMI chapters and their desire to setup a mentorship program for PMs...
http://www.linkedin.com/in/eflora

Excerpted from her public posting on Linked In:
"When we designed the mentoring program for the PMI Phoenix, we did a lot of research on what other chapters and SIGs were doing. Here is a listing of links to those programs. You should be able to find some good information here. You may also want to contact the chapters/SIGs directly to get information on lessons they learned, etc. Best of luck to you! :) Erika

Southern Alberta Canada http://www.pmisac.com/index.php?id=290

Northern Alberta Canada http://www.pminac.com/

Birmingham, Alabama http://capmichapter.tripod.com/id17.html

Southern New England http://www.snec-pmi.org/mem-is.php

Chicagoland http://www.pmi-chicagoland.org/mentoring/index.php

Central Illinois http://www.pmi-cic.org/education/mentoringprogram.htm

Kansas City Mid-America http://kcpmichapter.org/mentor.html

Nebraska Heartland http://www.pmiheartland.org/profdev/mentor.aspx

South Nevada http://www.pmi-snc.org/MentoringPMISNC.html

New York City http://www.pminyc.org/

Westchester, New York http://www.pmiwestchester.org/

Eastern North Carolina and Research Triangle Park http://www.ncpmi.org/index.phtml?menu=side_button&menu2=8&data=&data2=&sessionid=t1156548671m67471500&username=&password=&userhelp=off&cart=

Central Ohio http://www.pmicentralohio.com/User/Mentoring.aspx

Portland, Oregon http://www.pmi-portland.org/outreach/mentoring_outreach.htm

Memphis, Tennessee http://www.pmimemphis.org/mentor.shtml

Milwaukee, Southwest Wisconsin http://www.pmi-milwaukee.org/mentoring.asp

Links:
http://wipmsig.org/mentor.htm
http://www.phx-pmi.org/displaycommon.cfm?an=1&subarticlenbr=43
http://blog.erikaflora.com

Project Server Reporting DB and Custom Fields

If you look inside your project server reporting DB, you will notice there are several prebuilt views which show relationships between the standard project server objects (projects, resources, etc...) and the custom fields you have defined.

What you may not realize is that the custom fields are disjointed. They only relate at the point in time when you look at them.

for instance...
I use this DB extensively for compiling data and sending it to my company's accounting process. For this to work, I need to track the time sheet charges to the budget code they apply to. This works well and I am able to map this out (after navigating a few additional Unique IDs in the time sheet tables). Works fine in the cube too.

However, let's say we change the budget code so that from today forward, all charges go to a different department. No problem. Right? Next week I send over the same report with updated data. But If I am asked to go back and check my historical charges to either of these budget codes, I can no longer differentiate where the charges went or should have gone.

This is because the link between custom fields and the raw data in project server is not saved with the time sheets or projects as a "point in time" record. Most other time sheet systems do this to keep an accurate, accounting friendly, record of charges.

So, what to do? My approach has been to write a stored procedure that inserts the current changes and their related dates in a new table in the reporting DB. I do this nightly and have a query (i use it as a subquery as needed) that searches this and pulls back the correct value based on the desired timestamp. It's a suitable workaround, but I shouldn't have had to experience the root problem in the first place.

Perhaps MS will change this to match the way EPK and other vendors save time sheet data in the future.

I.P.E.C. in reality

So, you are likely familiar with the way in which most projects are broken down: Initiation, Planning, Executing and Closing (monitoring and controlling would be happening simultaneously to these). When I first started project management, most everyone approached these phases as gates. Hard stops for readjustment on your way to the end.


I used to have a form to fill out, where each stakeholder would sign off that this phase was complete. In practice, although we got the signatures, we rarely discussed the true meaning of this.


When I began working to integrate the WBS and the CPA sessions (see my earlier 3 part posts on this) we realized that we could still be as effective, in fact more so, by letting go of these "phases" and adopting a true shared understanding of the deliverables and their time lines.


We also began to realize that the I.P.E.C. phases were not really ever gates. We were always crossing the boundary. For instance: One task that fits squarely in Initiation, would need to occur after a task that fits squarely in planning. This rang true for all projects in our portfolio and all phases...
We came to see the I.P.E.C. phases in a new way. We draw them this way to explain to our customers what our "phases" look like. Then we explain where we are with our deliverables and this leads to a clearer understanding of the project and it's success. In fact, all status reports are deliverable based (again, see my WBS and CPA posts).

Softgrid and Project Server

This post comes from first hand experience. Our environment does not allow for much software personalization and no custom software installation. In order to ease the desk side visits, we opted for Softgrid as our means of rolling out the PWA active X controls and the Project Pro client. Softgrid functions as a virtual software utility. It installs a copy of the windows client (package) locally on your machine, and runs it in an isolated fashion when you launch it.

First the upsides:

• We only had to roll out the softgrid package and not the individual software.
• I, as a sole administrator, am able to add users to the software packages through editing an Exchange DL. Very rapid and pretty slick.
• Offline/laptop works very well under normal conditions.

Now the downsides:
While it has met our core requirement of ease of administration and transportability between systems, we have had some downsides.

• If a program changes, there can be a confusing user experience with the removal of the old package. the workaround is easy, eliminate the packages and resynch. However, this can be extremely slow when travelling based on the package size.
• A package is isolated. This means that should you require interoperability with other apps, this is unavailable. For example, try creating a new calendar for your project server. In this scenario, the client will try to spawn a browser and could fail if it is not included in context of the package.
• Multiple packages may need to be updated simultaneously. For example... You may wish to update the Project Pro client software at the same time as the End user active X controls. Coordinating the timing of this can be important.
• Resetting your app pool, resets any local preferences (such as the project server connection data in the Project Pro 2007 client)

Overall Softgrid has eased the pain of administration, but be aware of these current limitations when selecting your roll out strategy.