PMQu: A Quality Tool for Project Information in MS Project

pmicriticalpath201504(Article published first in “The Critical Path”, PMI Sydney, April 2015)

The open source add-in for MS Project called œPMQu assists project managers to create, and maintain, quality-checked project information. Earlier in this series of articles, I argued[1] for greater coherence between the WBS and Schedule Network, and then in the second article [2] introduced the means to automate this coherence by applying the new Schedule Network 100 percent rule and the Add and Prune Dependencies algorithm. This article introduces PMQu, a MS Project add-in that implements this rule and algorithm and other best practice quality checks. Firstly, we review the benefits of quality checking project information, and then, after pointing to the sources of the quality checks, the PMQu add-in is introduced and the article concludes with a short invitation to explore next steps.

Context, and why perform quality checks?

Managing quality, including that of project plans, is a management challenge involving both people and process. PMQu will automate just one aspect of process, which is, checking the conformance of plans to pre-agreed quality standards. This is an activity which is impractical to perform manually on real-world plans.

PMQu is intended for the professional project manager and Project Management Office (PMO) where each project’s WBS and Schedule Network may be contained within a single stand-alone MS Project plan of up to 300-350 activities. In this context there are at least four reasons for checking the quality of project information. Quality checking can:

  • Reduce, or eliminate, many common WBS and Schedule Network mistakes,
  • Improve the flexibility of schedules under rolling wave planning,
  • Improve the transferability of project plans between project managers,
  • Assist managers to induct new project managers to use a common style for project information.

For this context, from where has the author drawn the quality checks?

Sources of Quality Checks

Firstly, PMQu checks the coherence between the WBS and Schedule Network using the Schedule Network 100 percent rule and the Add and Prune Dependencies algorithm that were referred to earlier.

Secondly, and equally importantly, PMQu performs quality checks according to best practice guidance found in the following six recommended sources:

Naturally, not every piece of advice is checked.  Instead, PMQu checks an integrated set of guidance drawn from all these sources.

PMQu Add-in for MS Project

The PMQu open source add-in for MS Project 2010/2013 reads the current project and creates a report in the user’s browser covering 42 separate checks.  PMQu does not alter the current project.  Table 1. contains a breakdown of the quality checks by area with some examples:

Quality Check Area # of Checks Example Checks
Task Identity 4 Every task must have a unique name.
Work Breakdown Structure 7 Every summary component will have a minimum of two child components.The WBS will be coherent with the Schedule Network.
Schedule Network 12 Summary Tasks may not have dependencies.All tasks will participate in the Schedule Network.
Resources 4 Summary Tasks may not have resources assigned.
Scheduling 10 All tasks must have a duration specified.
Progress 5 Milestone’s %Complete must either be 0% or 100%.
Microsoft Project settings 18 Schedule From [Project Start Date].
TOTAL 42  

Table 1. “ A breakdown of the quality checks with some examples

Next steps

You are invited to install, and use, PMQu under the open source MIT license. The software itself, a list of all the checks, sample plans, and the installation and usage instructions may be found on GitHub at https://github.com/DavidPratten/PMQu . Your comments and questions are welcome via GitHub issues.

The author relies on the PMQu add-in for MS Project to check project information quality for his projects. How will you use it? The MIT license for the software means that you are free to use the intellectual property in this software for anything, including running your projects, as a resource for your PMO, for training project managers, and creating commercial opportunities. Go for it!

[1] Pratten, D. (2014). Having a common definition of œdeliverable in both WBS and the schedule network The Critical Path, 5(6), 16-17.  Retrieved from http://www.pmisydney.org/index.php/document-repository/doc_download/908-critical-path-december-2014

[2] Pratten, D. (2015). WBS and Schedule Network coherence at scale The Critical Path, 6(1), 14-16.  Retrieved from http://www.pmisydney.org/index.php/document-repository/doc_download/986-criticalpath201502volume6issue1

Expected % Complete MS Project Custom Column

I attended Angela Chellas’ MS Project Advanced workshop today (excellent course) and there was a question about how to figure out what % complete that a task should be if it was on track.  Based on elapsed time, the Expected % Complete for tasks and summary items may be calculated using a MS Project Custom Field.

[expand title=”Text of the formula – to paste in.”]

Int(
  IIf([Current Date]>=[Start]
     ,IIf([Current Date]<=[Finish],
        IIf([Duration]>0,
           ProjDateDiff([Start],[Current Date])/[Duration]*100
           ,IIf([Current Date]>=[Start],100,0))
        ,100)
     ,0)
)

[/expand]

 

You create the custom column like this.

customcol2

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…]