Sunday 30 August 2009

Critical tasks – how can I review this quickly? (part 1)

As you will have gathered there are different ways of entering and viewing data within project professional. Here are some of the ways to view critical tasks on your project;
    Detail Gantt View
    Gantt Chart Formatting Wizard
    Built-in filter for Critical Tasks
    Built-in Group for Critical Tasks
But first let’s recap on the definition of critical task/Path. This is best understood as “the series of tasks that must be completed on schedule for a project to finish on schedule. Each task on the critical path is a critical task”. If one task on the critical path moves, the end date of the project will move as well.

As you update your project by modifying tasks, be aware of the critical tasks and that changes to them will affect your delivery milestones and project finish date. It is therefore, important to review not just the critical tasks but also the non-critical tasks (with ‘float’) that can become critical as result of some change.

Detail Gantt View

You can access the view that displays the critical path via Views > More Views and applying the Detail Gantt View. See fig below.

CriticalTasks_2

(click picture to enlarge)

CriticalTasks_1

Gantt Chart Formatting Wizard 

On the View menu, click Gantt Chart, and then click Gantt Chart Wizard  on the Formatting toolbar or right clicking on the right hand side of the splitter bar and select ‘Gantt Chart Wizard’. Follow the instructions in the Gantt Chart Wizard to format the critical path as required.

CriticalTasks_5a

CriticalTasks_5b

CriticalTasks_5c

Using Built-in Filter for Critical Tasks

The alternative to above is that you can apply the built-in project filter ‘Critical’.

CriticalTasks_6

Using Built-in Group for Critical Tasks

The alternative to above is that you can apply the built-in project Grouping for ‘Critical’.

CriticalTasks_7

Here is a really good video demonstration from Microsoft office online that you will find useful.

video_button

Monday 24 August 2009

EPM2007 – controlling no. of Admin Categories appearing in Timesheet

I had a couple of queries regarding controlling the number of administrative categories that appear in EPM2007 timesheets. This is especially of concern when there are large numbers of admin categories say 10+. The users’ timesheet can appear large and unwieldy especially if they are also working on lots of smaller projects. 

My suggestion would be to set just the main admin categories (which applies to majority of the user base) as Always Display. The others should be left un-checked. See example in fig below.

Timesheeting_Admin0

(click picture to enlarge)

In the above example, Training admin category is setup such that it does not appear by default (i.e. Always Display check box is left unchecked). The example fig below shows default admin categories added when a timesheet is first created.

Timesheeting_Admin3 

The user can then add the additional (non-default) admin categories, as required, for the TS week via My Timesheet summary page > Plan Administrative Time and then selecting the appropriate TS period. You can either start adding the committed/planned time within the dialog box for administrative time or simply choose to save and then add the actual time within the timesheet against the non-default admin category that was saved.

Note: You cannot add non-default admin categories from within the already created/existing timesheet.

Timesheeting_Admin5 

The resulting example timesheet is shown in fig below.

Timesheeting_Admin6

Wednesday 19 August 2009

The Mistry Family at Alton Towers Theme Park (UK)

I had a fantastic few days off in Scotland. Also, been on thrill seeking rides at Alton Towers with the family. And, yes, I did conquer the Oblivion (free falling vertically 200ft downwards at a force of 4.5G's).

110

(click picture to enlarge)

Tuesday 18 August 2009

Making users/resource inactive – considerations

I had a query from a user regarding making resources inactive. Here are some of the implications and considerations;

  1. Making the Resource/User inactive will prevent the resource being available in the Build Team Dialog box for PMs i.e. they will not see these resources in Project Pro.
  2. Inactive users (also resource) will not be able to login to Project Pro or PWA.
  3. Inactive resources will still show in PWA > Resource Centre for the purpose of completeness i.e. checking which resource is active/inactive (left the company but were assigned on previous projects etc). Views can be setup/updated to show only the active resources (filtered).
  4. Inactive resources on ‘part-complete’ tasks/assignments should be replaced with other active resources. There will be warning when project is opened when inactive resource are in the team. See example below for replacing incomplete assignment.

InactiveResources_1

(click picture to enlarge)

InactiveResources_2

(click picture to enlarge)

Tuesday 4 August 2009

Project Publish error 26000 – Database Corruption!

Issue

I recently came across an issue whereby some projects where publishing fine for some users and others where failing. After say a few tries, the same project would fail to publish with the dreaded 26000 error!

Publish_Error 26000

(click picture to enlarge)

<?xml version="1.0" encoding="utf-16"?>
<errinfo>
<general>
  <class name="Queue">
   <error id="26000" name="GeneralQueueJobFailed" uid="8bf04958-b8c1-47ac-bfc9-a0bbebb59238" JobUID="cf6c2adb-22c4-43a8-bed8-e52113705c66" ComputerName="TAVMPS01" GroupType="ProjectPublish" MessageType="PublishProjectMessage" MessageId="135" Stage=""/>
  </class>
</general>
</errinfo>

Investigation

The only other time I had seen this before was when the RTM update had failed leading to binaries being at a patch level different to the databases. Not this time!

I checked the patch levels of each database and also the client apps. This was confusing! How can a project publish perfectly well as many as 10 times and then suddenly fail! The inconsistency was worrying and hard to troubleshoot.

- the SharePoint Config Wizard (SCW) indicated no problems with the farm

- projects were saving and checking in fine.

On closer examination of the ULS logs (throttled for verbose) I determined that there was a possible issue with a procedure in the Published SQL DB.  This was not a good sign.

 Publish_Error 26000_Database Corruption_ULS

(click picture to enlarge)

I then ran the database integrity check on the Published database and this pointed to database corruption! Error 8967 is not a good sign! but, at least I knew what the cause of the issue was.

This error was somewhat similar to another SQL issue http://support.microsoft.com/kb/960791/en-us. It did not, however, cover my exact scenario, but, was an indicator of the type of issue I was facing.

Publish_Error 26000_Database Corruption_v2

(click picture to enlarge)

Resolution

To resolve the issue the options were;

  1. Repair the SQL database (REPAIR_ALLOW_DATA_LOSS, REPAIR_FAST, REPAIR_REBUILD). Note: use the first option repair with data loss option only as a last resort as this may render your system unusable. Test the other repair options first on a test/development environment first before applying to live.
  2. Restore previous ‘good’ backup of the SQL databases
  3. Restore from previous SharePoint farm backup

I went for Option (2) above and everything started working fine. We had to replicate some of the changes as the ‘good’ DB backup copy was slightly older.

Recommendation

Avoid using option (1) above i.e. repairing the DB with data loss unless absolutely necessary and no other options are viable. This is no guarantee of a fix. If you want to try the other SQL database repair options then test thoroughly on a test environment first before applying on live.

I would recommend option (2) to fix this type of issue. Note: remember to restore all four project server databases and associated content DB. Do not be tempted to mix and match i.e. single DB restore.

This just goes to show how important it is to ensure that you have a proper SQL database backup maintenance plan setup (with verification) as per your business data loss (and DR) policy. Not only this, but it important to also do a restore test on a test/dev environment on a regular basis say every quarter. Stay tuned for post on recommended strategy for Disaster Recovery.

Note: This posting is provided "AS IS" with no warranties, and confers no rights.