Draft ISO 21500 Standard, a first look at the input/output model

Last Thursday, June 7, I visit an information session regarding this new ISO 21500 standard. This standard provides generic guidance on the concept and processes of project management that are important for and have impact on the achievement of projects.

You can find this standard (http://www.normontwerpen.nen.nl/Home/Details/104).

In this guidance on project management you will find 40 processes cross-referenced to Process (Initiating, Planning, Implementing, Controlling, Closing) and Subject Groups (Integration, Stakeholder, Scope, Resource, Time, Cost, Risk, Quality, Procurement, Communication).

This international standard is not intended to:

–       Replace a national standard or be used as such; or

–       Be used in any way for certification or regulatory purposes.

This means this standard will not replace PRINCE2 or PMBoK or other standards, but it provides overarching guidance for project management.

For every process it gives the primary inputs and outputs. When I see these kind of tables, I want to see if it’s consistent. To perform this check I created a map to show all deliverables  s (like I did with my Quick Reference Card for PRINCE2). Based on this map I have some questions to share:

–       Not all deliverables/products are output of a process. Sometimes this is correct, when the deliverable is coming from the outside world. But this is not always the case (e.g. Deliverables, Business Case are only used as input and not created or updated by one of the processes). Does this mean that this standard is not based on a continuous business justification?

–       The focus is on the Project manager. I miss the focuss of the executive (or Sponsor as it’s called here). For me senior management is key in the success of a project. Project governance needs more attention in this guideline as well as a specific process like we have in PRINCE2 (Directing a Project).

–       Some output is rather detailed. Not sure if this is needed. Look e.g. at all deliverables related to activities (sequence, duration estimates, list, work breakdown). For me, this focus on activities in this guideline is a step backwards. I don’t believe in communication about activities. For me the focus must be products or deliverables. Why not have a Product Breakdown structure to communicate the scope, the measure progress against?

–       Look at deliverables related to Risk. Keep it simple and use the Risk Register as on deliverable to be created, used and updated by the processes.

–       Why are Staff Performance and Staff appraisals outputs from the process Controlling and Why are Team Performance and Team appraisals outputs from the process Implementing.

–       We have Registers and Logs. In PRINCE2 terms Registers are forma land Logs are informal.

Probably you will find more questions if you give this map a closer look. On the other hand I think it’s a good idea to create a sort of common language regarding Project Management. This will help to bridge the gap between organizations or groups using different project management methodologies. At this moment it’s still a draft, which needs some improvement especially in the areas of the Business Case, Project Governance and the Product Breakdown structure. We also need to simplify this map to make communication easier. I am looking forward to reactions.