Discovered some gaps in my knowledge (migration from 2003 and 2007). Some questions are stupid, made not for knowledge, but for reading the questions.
Merging 2 instances of Project Server 2010 into one instance
Anton Kravtsov
Right now I am working on merging of 2 instances of Project Server 2010 into single one.
2 departments started PS2010 trials independently; were running it for about 6 month and performed number of customizations:
Proposed strategy is to pick one instance that is more "clean" and less "messy" and have it as "master" instance and merge another instance into this one.
So approach will look like:
The easiest workaround for moving projects between instances is to save all task level custom fields into standard local column (Text1..., Number1...) using Copy-Paste of columns, save a local copy, upload to destination server and copy values back to Enterprise custom fields.
I will update this post if will find one missing steps.
Update: We've developed a product - FluentBooks that allows configuration migration, merge and documenting. You can learn more here or watch a sample video in another our blogpost.
2 departments started PS2010 trials independently; were running it for about 6 month and performed number of customizations:
- customer fields (project and task level). Some fields have matching name and different meaning / values and some fields have different name but same purpose
- different EPTs
- different Project Site templates (that's the most easiest problem to solve)
- one is using Single Entry, second one is using Free Form for progress reporting and no time sheets.
Proposed strategy is to pick one instance that is more "clean" and less "messy" and have it as "master" instance and merge another instance into this one.
So approach will look like:
- Backup instances
- Pick one instance as master (I1).
- Export project site template from I2
- Import site template into I1
- Unify custom fields
- Try applying Playbook from I1 and then from I2 into 3rd instance to see the conflicts, rename fields /lookups in I2 if required. If not working out - move it manually
- Export project from I2 as will be described below
- Import projects as described above
- Have PMs to edit new projects to have same project ECF values as in old system (This can be automated with FluentPro's ECF Migrator tool)
- Copy resource pool from I2 via Project Pro into I1
- Import resources
- Replace resources in project
- export project sites from I2 with STS-ADM
- import project sites into I2
- Point projects into new sites
- Verify everything :-)
The easiest workaround for moving projects between instances is to save all task level custom fields into standard local column (Text1..., Number1...) using Copy-Paste of columns, save a local copy, upload to destination server and copy values back to Enterprise custom fields.
I will update this post if will find one missing steps.
Update: We've developed a product - FluentBooks that allows configuration migration, merge and documenting. You can learn more here or watch a sample video in another our blogpost.
Reviewing Project Server 2010 Implementation
Anton Kravtsov
Today was on a call with company that had implementation of PS by quite big EPM partner. This was ugly.
- To display milestones on Project workspace they put schedule control.
- On Status Report page instead of displaying information they have a mix - data entry and some display.
- Status Report is not printable and like 1500 pixels wide
- To create a page to display risks and issues from all projects they read from number of sites but display just name.
- In custom fields there are like 30 extra fields that never were used - looks left from 3rd party solution.
Project Server 2010 Solution Starters - feedback from customers
Anton Kravtsov
After being involved in Project Server 2010 Solution Starters development, we are always pleased to see that companies who are implementing / using Project Server 2010 utilize some of the solution starters. From our experience, most popular ones are Dynamic Workflow, Bulk Edit and Bulk Import.
Here I wanted to share some ideas / problems from customers who are using them.
Dynamic workflow
Bulk Edit
Bulk Import
Here I wanted to share some ideas / problems from customers who are using them.
Dynamic workflow
- ability to send email when moving between stages
Bulk Edit
- Works slow on big number of projects (over 50) (we have customizations with reading data from RDB but writing via PSI)
- Some customers want projects to be checked-in after editing
- Correct handling of session end (we heard one comment from user on this and it is more our guess
Bulk Import
- using custom fields with lookup tables and populating values.
Portfolio and Programs in Project Server
Anton Kravtsov
In this post I will cover how we can create a support of Programs and Portfolio Functionality in Project Server 2010.
By definition, project is "a temporary endeavor undertaken to create a unique product, service or result". Program can consist one or more Projects that are delivering within one initiative; Portfolio can consist one or more Programs or Projects and is more strategic grouping.
Usually, Program can have its own schedule ignoring the fact that it can contain more than one project which can define the duration, start / end dates; Logic behind giving ability to have own schedule is based on fact that there might be activities that has to be tracked on Program level.
We can use the same logic for Portfolio, but in reality portfolio is a more a matter of "grouping" projects for reporting / structuring projects within organizational strategy.
My suggestion is to have 2 lookup tables and 3 custom fields on Project Level:
Lookup tables:
LT Program
LT Portfolio
Custom fields:
Is Program (Flag)
Program (Referencing LT Program)
Portfolio (Referencing LT Portfolio)
Program is defined as project with Program field empty and Is Program field checked; Program can have value in Portfolio field.
Project has Is Program field unchecked; Project can have values in both Program and Portfolio fields.
Portfolio is just grouping value;
As significant improvement for managing lookup tables is to develop event handler on project save that will populate LT Program lookup table dynamically, otherwise you have to maintain it manually.
As part of effort, I would recommend to create several reports:
By definition, project is "a temporary endeavor undertaken to create a unique product, service or result". Program can consist one or more Projects that are delivering within one initiative; Portfolio can consist one or more Programs or Projects and is more strategic grouping.
Usually, Program can have its own schedule ignoring the fact that it can contain more than one project which can define the duration, start / end dates; Logic behind giving ability to have own schedule is based on fact that there might be activities that has to be tracked on Program level.
We can use the same logic for Portfolio, but in reality portfolio is a more a matter of "grouping" projects for reporting / structuring projects within organizational strategy.
My suggestion is to have 2 lookup tables and 3 custom fields on Project Level:
Lookup tables:
LT Program
LT Portfolio
Custom fields:
Is Program (Flag)
Program (Referencing LT Program)
Portfolio (Referencing LT Portfolio)
Program is defined as project with Program field empty and Is Program field checked; Program can have value in Portfolio field.
Project has Is Program field unchecked; Project can have values in both Program and Portfolio fields.
Portfolio is just grouping value;
As significant improvement for managing lookup tables is to develop event handler on project save that will populate LT Program lookup table dynamically, otherwise you have to maintain it manually.
As part of effort, I would recommend to create several reports:
- Programs Overview (list of programs in Program with indicators
- Program Details
- Portfolio Overview (list of projects / programs in Portfolio with indicators)
FluentPro Reports Pack
Anton Kravtsov
After working on number of customer engagements and developing over 100 reports, we've decided to kick-off "assembly" of our own report pack. This report pack will include set of reports and set of custom fields that customers will have to add to the system in order to be able to use reports.
Report pack will contain approximately 20 reports:
Update:
We have several available reporting packages:
Report pack will contain approximately 20 reports:
- Several Executive dashboards
- Timesheet reports (weekly and monthly views)
- Status update reports (weekly and monthly views)
- Portfolio and Program overview
- Project overview
- Milestones overview
- Capitalization reports
Update:
We have several available reporting packages:
- Project Status report: http://www.fluentpro.com/productsstatusreport.html
- Project Dashboard: http://www.fluentpro.com/productsprojectdashboard.html
- Timesheet reports: http://www.fluentpro.com/productstimereports.html
Russian / Ukrainian community - Project Server 2010
Anton Kravtsov
Our company started re-design of www.projectserver.com.ua to make it more community oriented site related to Project Server 2010. In Russia and Ukraine market is very small and it is close to impossible to find nice content that easy to use. So, we've decided that during next 3 month our company will do:
- Re-design site and make popular content with videos available
- Arrange about 10 free web seminars about project server (hopefully will get some support from Microsoft)
- Publish our videos and guides
- Create a section with best practices / workflow samples
Project Server 2010 Reporting
Anton Kravtsov
Microsoft published nice document on Project Server 2010 Reporting at http://technet.microsoft.com/en-au/library/gg188101.aspx
It covers Excel Services, SSRS, OLAP, Performance Point.
We've started working on a check lists, guides and videos for configuring Excel Services, Analysis Services, Reporting Services for Project Server 2010 and plan to publish it for English and Russian content within next 30 days.
It covers Excel Services, SSRS, OLAP, Performance Point.
We've started working on a check lists, guides and videos for configuring Excel Services, Analysis Services, Reporting Services for Project Server 2010 and plan to publish it for English and Russian content within next 30 days.
Strange error in Project Server 2010 formulas in custom field
Anton Kravtsov
Today, we've found strange error that disappeared after restarting IIS. We had a project level custom field (Flag) referencing task custom field as [Task Field Name].
For some very strange reason we were able to change value of Project Custom Field with formula in Project Pro (Server and PPro are with December CU). This was possible only in P Pro, not in PWA. After restarting IIS this behavior was gone; Very odd.
For some very strange reason we were able to change value of Project Custom Field with formula in Project Pro (Server and PPro are with December CU). This was possible only in P Pro, not in PWA. After restarting IIS this behavior was gone; Very odd.
Workflow development - sharing our experience
Anton Kravtsov
I would like to highlight several items that we've learned after developing several complex workflows for our customers.
- Start with workflow design, email notifications and email templates definition, define PDPs and fields that are required / visible on every stage
- Create fields dynamically if possible, so your workflow can work on different environments (dev, staging, production)
- Send notification emails on every change of control or change of ownership
- Change Project Owner if your workflow expects more than just and approval
- Check-in project when change ownership
- Use SharePoint mail for sending emails (Project Server Notifications could be disabled)
- Use event log for logging every steps in your workflow (helps to debug it); Log emails sent by workflow (who, when, where). More you log - more stable and tested your workflow is since debugging is not an easy one.
- Use automated deployment scripts for installing workflow
- Backup previous versions of workflow before installing new ones
One more workflow design
Anton Kravtsov
In current time, many organizations require process/project initiation process. In other words, every project that is created in organization has to meet not only business / financial requirements but also meet criterias defined by Project Management Office.
This workflow defines a simple workflow that can be implemented in Project Server 2010. Compared to previous workflow, the only approver is PMO director, and persons is responsible for making sure that projects meet required standards and only approve ones that meet or reject / request a change for one's that do not meet it.
This workflow also assumes change of ownership of project from Submitter to Project Director and then to Project Manager.
In few next posts we will provide modification overview of current workflows for Portfolio Analysis integration.
This workflow defines a simple workflow that can be implemented in Project Server 2010. Compared to previous workflow, the only approver is PMO director, and persons is responsible for making sure that projects meet required standards and only approve ones that meet or reject / request a change for one's that do not meet it.
This workflow also assumes change of ownership of project from Submitter to Project Director and then to Project Manager.
In few next posts we will provide modification overview of current workflows for Portfolio Analysis integration.
Problem Project Professional 2010 - Workflow enabled fields and multiline fields
Anton Kravtsov
For some reason, workflow-enabled fields are not visible in MS Project Pro as well as multiline text. I can find logical explanation why MS did this; But - why not to go one step ahead and make them visible and read-only?
Transfer of Values between custom fields
Anton Kravtsov
Working on number of Project Server 2007 to 2010 upgrades, out team faced number of issues with clearing metadata, especially custom fields. We also met these issue few times doing customizations / audits of Project Server 2010 implementations.
Typical problem is that some fields at customer's systems were using custom lookup tables with custom values - for example Yes, No, TDB (or different set of values); Then customer decides to move to Flag type for this field; or customer was using description field for capturing project summary but then decides to move to special field.
It sounds quite easy - delete fields and create ones; But if you have over 1000 projects, that becomes quite complicated, since efforts to update / transfer those fields manually is quite big.
Second option - go to DB (published) and do SQL update ( Strongly not recommended by Microsoft).
3rd option - create tool and do it via PSI.
So, we've developed a tool that allows conditional transfer / conversion of fields using PSI. It is not fast (it takes about 5 to 300 seconds) for full cycle depending on project size / farm or single WFE / event handlers, but you usually run tool just once.
Case: Field Enterprise project type has values - Enterprise Project, Non - Enterprise, TBD. Field is not required, no default value. Idea is to create new field Enterprise Project - Flag, rename old field, update all projects and set:
1. if Value = Enterprise Project, set Value = 1
2. if Value =TBD, Non-Enterprise or Empty Set Value = 0.
3. Save and publish project.
Tool is developed as WinForms application that allows to define number of such rules applied for the project. Tool iterates all projects (can specify Draft or Published only or all) and applies rules, saves and publish projects, so all data become visible.
Side effect - sometimes projects that sit in Draft for months become published :-)
Tool is available for purchase.
Typical problem is that some fields at customer's systems were using custom lookup tables with custom values - for example Yes, No, TDB (or different set of values); Then customer decides to move to Flag type for this field; or customer was using description field for capturing project summary but then decides to move to special field.
It sounds quite easy - delete fields and create ones; But if you have over 1000 projects, that becomes quite complicated, since efforts to update / transfer those fields manually is quite big.
Second option - go to DB (published) and do SQL update ( Strongly not recommended by Microsoft).
3rd option - create tool and do it via PSI.
So, we've developed a tool that allows conditional transfer / conversion of fields using PSI. It is not fast (it takes about 5 to 300 seconds) for full cycle depending on project size / farm or single WFE / event handlers, but you usually run tool just once.
Case: Field Enterprise project type has values - Enterprise Project, Non - Enterprise, TBD. Field is not required, no default value. Idea is to create new field Enterprise Project - Flag, rename old field, update all projects and set:
1. if Value = Enterprise Project, set Value = 1
2. if Value =TBD, Non-Enterprise or Empty Set Value = 0.
3. Save and publish project.
Tool is developed as WinForms application that allows to define number of such rules applied for the project. Tool iterates all projects (can specify Draft or Published only or all) and applies rules, saves and publish projects, so all data become visible.
Side effect - sometimes projects that sit in Draft for months become published :-)
Tool is available for purchase.
Project Server 2010 - Dynamic Approvals Workflow
Anton Kravtsov
In February 2010, our team completed migration of Project Server 2007 system to Project Server 2010 platform with additional customization work. Original system contained over 1000 projects with about about 300 active projects in execution phase.
As part of the migration, our client wanted to perform number of improvements in their current project initiation process, so we designed and implemented a workflow for that.
There are number of nice features that I wanted to highlight:
- Ability to define up to five approvers and dynamically specify if their approval is mandatory. This is done by utilizing 10 custom fields for approvers and requirement for approval with some front-end javascript code for making all fields as required.
- On every change of ownership / action required system sends emails to all parties notifying of required actions.
- Most of the approvals have 3 states - approve, reject, request for more information.
- We've implemented detailed log trail for audit and maintenance using Event Log.
Challenges
- Dynamic project permissions management - since there are several owners during project life cycle plus number of additional key resources that need ability to access specific project only, we are dynamically give permissions for this project for specific users, this is done by workflow.
- Customer wanted Auto ID (user friendly of-course) generation - done with event handler and SharePoint list.
- There are number of project types (EPT), and depending on selected EPT, workflow routes project to specific manager in PMO. This is done with special routing table.
- Force check-in on ownership change: When workflow changes owner, it should do force check-in and publish, so another user can edit / provide information.
FluentPS v.2.0 is available
Anton Kravtsov
We are happy to announce release of FluentPS v.2.0 - open source library for Project Server 2010 development and customizations.
Please find more details at htp://www.projectserver2010blog.com
Please find more details at htp://www.projectserver2010blog.com
Subscribe to:
Posts (Atom)