Indentifying Configuration Items and MS Project

clsPermanentID-10This post explores a way of using MS Project to automatically allocate a permanent identifying number to a project’s configuration items.

Within PRINCE2 project management guidance, configuration management depends, in part, on being able to uniquely (and permanently) identify project products.

For projects which are using MS Project as the tool to document the Product Breakdown Structure (PBS) and Project Schedule – it would be convenient if MS Project automatically allocated a unique and permanent identifier to all items in the MS Project plan.

During planning, sections of the PBS and Project Schedule are subject to elaboration and reframing, particularly as more knowledge becomes available.  This means that the permanent identifier of configuration items should survive reorganisation of the PBS and schedule.

The remainer of this post explains why the existing fields in MS Project are not fit for this purpose and how a permanent unique identifier may be automatically generated.

In the description below, “task” is used as it is in MS Project, meaning one item in an MS Project plan that could be a summary element in a PBS or WBS or an individual task.

Firstly, lets look at why the ID, WBS Code, and Unique ID fields do not provide the required uniqueness and permanence.

  1. The ID numbers allocated by MS Project are neither unique nor permanent.  As an MS Project plan is sorted, the ID numbers may be reallocated. In addition, if a task is deleted, the ID will be allocated again to another entry.
  2. The WBS code is neither unique nor permanent.  If a project product’s entry is moved to a different part of the PBS (or WBS) hierarchy the WBS code will change.  The WBS Code will then be allocated to the entry that occupies the spot in the hierarchy that was vacated by the moved entry.
  3. Finally, the Unique ID field is unique but is not permanent. A task’s Unique ID value is unique because it is only allocated once and never reused.  However, the Unique ID for a task is not permanent, it will change if the item is cut and pasted back into the MS Project plan.  The only way to reliably move a task from one place in the PBS (or WBS) hierarchy to another, is to cut it from place and then paste it into its destination location.  In the process, MS Project will allocate the pasted task a new Unique ID. The original Unique ID is lost.

So, how may we get MS Project to automatically allocate an ID that is both unique and permanent? This may be achieved by adding a macro to the MS Project plan, and designating one of the “Number” fields as the “Permanent ID” for the entry.

Here are the installation steps, shown in Project 2010.
[Read more…]

Lightweight Project Management

Good to be blogging again after a three month hiatus.

The Work Breakdown Structure has caught my attention. The work breakdown structure is foundational to project management. My insight today is that the WBS could also be foundation to a task management tool. The beauty of the WBS is the way that it assists in enumerating ALL the work and ONLY the work involved in a project – this idea is a way to leverage this ability in a lightweight way with an easy migration to a sophisticated PM tool.

I imagine a WBS creation tool like Freemind with its fluid and fast interface. The leaves of the tree are work packages which naturally degenerate to tasks.

For simple projects, one view of the WBS would present only the leaves of the tree (ie only the tasks) as a reorderable list. Tasks could then be assigned to a day and checked off when done like other task managers.

When the task view is not powerful enough the tool would allow the full power of a Project Management (PM) tool like openproj to be applied to the same WBS and work packages/ tasks.

If dependences between parts of the WBS are added using the PM tool then the task view would show the tasks in clusters based on the dependencies.