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.

Advertisements

2 responses to “Draft ISO 21500 Standard, a first look at the input/output model

  1. Hi, from where can I download the draft?

  2. Responding to your comment “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?” I offer the following opinion / comments
    I agree that the output of any project is the product or deliverables, but I disagree with your apparent position that activites are not worth communicating about. It has been my experience in 35 of project work / management that only focussing on deliverables misses 20-30% of all project activity and usually results in an overrun of budgets in all but the simplest of jobs.
    I would postulate (1) all deliverables are the output of one or more activities, (2) not all activities result in deliverables but do consume time and resources (and must, therefore be tracked and controlled), and (3) that a properly written Scope of Work must include this Product Breakdown Structure you refer to above.
    Regards, Stephen Preston, PMP, Senior Project Manager, Jacobs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s