W24_SJP_Knowledge Enhancement for GPC ELPC Examinations (Part 3)

Issue Identification and Appraisal

As mentioned in the Blog 22, the final few blogs will look at areas where my knowledge is lacking and needs to be enhanced in order to increase my opportunities for be in good standing for doing the final examination.

The GPC’s self-assessment questionnaire uncovered a few deficient knowledgeable areas that need addressing. In order to better understand the subject areas development of blogs to assist learning about the areas is a way to better absorb the content. The final few blogs will all have the same problem statement, “What subject areas need knowledge advancement prior to undertaking the GPC Expert Level Project Controls examination?”

Feasible Alternatives

The deficient subject areas can be termed feasible alternatives, and these are:

  • Monte Carlo Simulation – covered in Blog 23
  • Configuration Management
  • BIM Modelling
  • Project Forensics
  • Stakeholder Engagement – covered in Blog 22
  • Contract Selection
  • Management Competencies

The above list is based on the results from the GPC’s self-assessment which was performed in May’2017 and is a summary of seven areas that need enhancement in the coming weeks. Hopefully a blog can be developed for each item during the remaining weeks the course runs. For Blog 24, the subject will be “Configuration Management’, a subject which the author was not aware off until reading the GPCCAR’s module M10-5 – Configuration Management, however it turns out it is just another name for Project Change Management as adopted in the IT and Systems Engineering projects in the Defence and related industries. Certainly, within the Companies the author has worked for in Oil and Gas Industry this term has not been used to date, not to say that it will not be used in the future, and so expanding my knowledge to better understand how this process is used will certainly broaden my experience as a practitioner.

Develop the Outcomes for each

Each remaining blog will develop an outcome for each ‘Feasible alternative’ (FA) subject as the subject gets reviewed, it will not identify an outcome for the other FA’s in that blog.

Configuration Management has a section devoted to it within the GPCCAR, M10-5 – “Configuration Management”, which introduces the principle, and then runs through basic tools, advanced tools types, as well as providing what outputs are expected. The CAR also provides some additional references and templates which are very informative.

Figure 1 – Configuration Management Process Map from the GPCCAR

Selection Criteria

Review of the GPC self-assessment items shows that there are four items to be addressed, see table 1 below.

Table 1 – Configuration Management items in GPCCAR Self-assessment

As the subject although familiar to the author in its original state of “Project Change Management” covers an industry which is not familiar to the author so to better understand them, Module 10.5 of the GPCCAR will be reviewed and documented in this blog, along with further comparisons from on-line research as necessary.

Analysis and Comparison of the Alternatives

The origins of Configuration Management (CM) go back to the 1950’s, but came more into ‘fashion’ in the 1980’s with the commencement of the IT and software development era.

Given the complexity of Billion dollar projects, the CM process tends to be heavy on bureaucracy, like those done by NASA. The GPCCAR goes on to advise that project control practitioners no matter whether working for owners or contractors or industry should familiar themselves with the processes, furthermore it suggests review of the excellent templates it contains incase the organization the practitioner is currently employed with does not have a robust change management system in place.

“Configuration management (CM) is the detailed recording and updating of information that describes an enterprise’s hardware and software. Such information typically includes the versions and updates that have been applied to installed software packages and the locations and network addresses of hardware devices. Special configuration management software is available. When a system needs a hardware or software upgrade, a computer technician can access the configuration management program and database to see what is currently installed. The technician can then make a more informed decision about the upgrade needed.” – Rouse, Margaret (2014)

Using the CM application enables the review of multiple systems to ensure any changes made to one system are incorporated in other systems or that the change made is not affecting the others. When used in software development, CM is called Unified Configuration Management (UCM) and it allows developers to keep track of source code, documentation, issues, and change management (requests and implemented).

In figure 2 below, the demonstration of the Asset Lifespan and where CM commences can be seen, the ‘V’ shape in the illustration demonstrating the project lifespan and the horizontal ‘Top line’ the rest of the lifespan from conception to retirement.

Figure 2 – Configuration Management Life Span as a function of the Asset Life Span

Figure 3 provides a more detailed view of the CM Process.

Figure 3 – Configuration Management Process

The GPCCAR indicates that three databases are required inputs; Cost Estimating DB, Scheduling DB, and Productivity DBs.

As noted above, there are four items requiring answers, which will be dealt with individually in order to satisfy what maybe be requested in the pending examinations. These four items are centered around the Tools and Techniques and probably best to summarize each section to cover what is required for the examination questions (should this subject arise).

Item 1 – Basic Configuration Management (GPCCAR Module 10.5.3.1)

Basic toolsets should:

  • Permit the structured definition, identification and storage of configuration items. The file systems of operating systems allow storage of CIs in files. A file system should object if the user tries to create a file with the same name as an existing file, i.e. it should ensure that names are unique.
  • Permit the structured storage of configuration items. The file systems of operating systems should allow the creation of directory trees for storing files.
  • Provide a librarian system that supports: – insertion of modules; – extraction of modules; – replacement of modules by updated modules; – deletion of modules; – production of cross-reference listings to show which modules refer to which; – storage of the transaction history; – all the above features for both source (i.e. text) and object (i.e. binary) files.
  • Provide facilities for building executable software from designated sources. This implies the capability to create a command file of build instructions with a text editor.
  • Provide security features so that access to CIs can be restricted to authorized personnel. This means that the operating system should allow the owner of a file to control access to it.
  • Provide facilities for comparing source modules so that changes can be identified. Most operating systems provide a tool for differencing ASCII files.
  • Include tools for the systematic backup of CIs. Specifically: – automatic electronic labelling of media; – complete system backup; – incremental backup; – restore; – production of backup logs. Most operating systems have commands for backing-up and restoring files

Item 2 – Advanced Configuration Management (GPCCAR Module 10.5.3.2)

As a supplement to the basic toolsets, advanced toolkits are sometimes required.

Advanced toolsets should:

  • Supplement the basic toolset with standalone tools such as source code control systems and module management systems. The extra capability requirements for an advanced toolset are listed below.
  • Provide a locking system with the library to ensure that only one person can work on a module at a time. Most operating system librarians do not provide this feature; it is a characteristic of dedicated software configuration management librarian tools.
  • Minimize the storage space needed. One way to do this is store the latest version and the changes, usually called ‘deltas’, required to generate earlier versions.
  • Allow long names to be used in identifiers. Some operating systems force the use of shorter names than the compiler or programming language standard allows, and this can make it impossible to make the configuration identifiers contain the names used in design.
  • Permit rollback, so that software configuration management operations can be undone. A simple but highly desirable type of backtracking operation is the ‘undelete’. Some tools can reverse deletion operations.
  • Provide facilities for rebuilding executable software from up-to-date versions of designated sources. This capability requires the build tool to examine the dependencies between the modules in the build and recompile those modules that have been changed since the last build.
  • Record the version of each module that was used to build a product baseline, so that product baselines can always be reproduced.
  • Provide facilities for the handling of configuration status accounts, specifically:
    • insertion of new RID, SPR, SCR and SMR status records;
    • modification of RID, SPR, SCR and SMR status records;
    • deletion of RID, SPR, SCR and SMR status records;
    • search of RID, SPR, SCR and SMR records on any field;
    • differencing of configuration status accounts, so that changes can be identified; – report generation.

Item 3 – Online Configuration Management (GPCCAR Module 10.5.3.3)

Online toolsets supplement the capabilities of advanced toolsets by providing facilities for interactive entry of change control information. The extra capability requirements for an online toolset are listed below:

Online Toolsets should:

  • Provide facilities for the direct entry of RID, SPR, SCR and SMR information into the database;
  • Provide an authentication system that permits online approval of changes.

Item 4 – Integrated Configuration Management (GPCCAR Module 10.5.3.4)

Integrated toolsets supplement the capabilities of online toolsets by extending the change control system to documentation. Integrated Toolsets form part of so-called ‘Integrated Project Support Environments’ (IPSEs), ‘Project Support Environments’ (PSEs) and ‘Software Development Environments’ (SDEs). The extra capabilities of an integrated toolset are listed below:

  • Recognize all the dependencies between CIs, so that consistency can be controlled. This capability requires a super-library called a ‘repository’. The Online Toolset has to be integrated with the CASE tools used for design. This facility permits the system to be automatically rebuilt from a design change, not just a code change.
  • Have standard interfaces to other tools (e.g. project management tools). Standards for interfacing software tools have been proposed, such as the Portable Common Tools Environment (PCTE) and the Common APSE Interface Set (CAIS)

The outputs that are expected based on the above Inputs are:

  • Scope Definition Down to Level 3 Or Preferably Level 4 Before Execution Starts
  • Approved Performance Measurement Baseline in-Place
  • Approved or Rejected Change Orders
  • Minimized Change Orders, Disputes and Claims

Selection of Preferred Alternative

There are no preferred alternatives in this case, all 4 items listed above are needed to enhance current knowledgebase ahead of the GPC ELPC Examination.

Monitoring Post Evaluation Performance

Post evaluation monitoring will be to see if what has been provided above has been fully understood and useful to assist successful passing of the examination, and then used on future projects to demonstrate the effectiveness and value of what a Project Control Practitioner provides to the project team, and decision-making process.

References

  • Guild of Project Controls. (October 3, 2015). M10-5 – Configuration Management – Guild of project controls compendium and reference (CaR) | Project controls – planning, scheduling, cost management and forensic analysis (Planning Planet). Retrieved November 01, 2017 from http://www.planningplanet.com/guild/gpccar/managing-change-configuration-management
  • Davis, G. (2009, May 8). Software configuration management. Retrieved from https://www.slideshare.net/guy_davis/software-configuration-management-1405640
  • Eaton, D. (2007, February 22). Configuration management tools summary [Web log post]. Retrieved from http://www.daveeaton.com/scm/CMTools.html

 

 

One Reply to “W24_SJP_Knowledge Enhancement for GPC ELPC Examinations (Part 3)”

  1. That should be more than enough to prepare you for any questions you may get on the GPC exams!!!

    Great job and you are going to be as well prepared as anyone for these exams.

    BR,
    Dr. PDG, Muscat, Oman

     

Leave a Reply

Your email address will not be published. Required fields are marked *