Standardize Project Perform Quality Assurance Process

Standardize Project Perform Quality Assurance Process The standardization of the quality assurance process is a methodology that is developed by an organization to ensure that quality is always something in the forefront of the project management team’s mind.  The standardization of the process involves the creation of the process of metrics for process systems, benchmarking utilizing these metrics, threshold development and tolerance, and quality audits to determine if the system when deployed is fully functioning.  The development of the QA system for the organization is a process that may be proprietary, but is developed in such a way that it is nonspecific enough to encompass many future projects, but specific enough it can be used time and time again.  The development of a checklist approach may be most useful in this situation, where we don’t want to leave anything out when we are working with this type of system. The standardization process is the development of the checklist as a wbs entry, and the adaptation of these specific standardized steps into the project.  This process seems difficult to standardize, but the process is not the same as many others that can be standardized, it is a process that is developed not specifically for the repeatability across future projects of the exact same wbs dictionary entry, but of a system that can be used to effectively across projects to identify the components of quality that will be utilized, and how to determine if quality assurance measures have detected defects. A system of forms, templates, checklists, flow diagrams, and audit able systems will need to be a part of this standardization effort.  The processes will be used to develop a best practice for the identification of the modular components necessary for the governance of a quality assurance process.  This will be added to the PMO as the de facto process used to develop a quality assurance system for a project.  The product of this process will be a system that shares many components of those used in the past, but is tailored to the specific needs of a certain project.  In order for this to be successful it is necessary to add all of these processes as work packages under one or more wbs entries and describe them with attached forms, templates, and checklists in the wbs dictionary.  These become modular wbs components that will be utilized across the enterprise. The development of standardization of quality assurance processes is difficult, because each project will have a unique tolerance, metrics, and thresholds that will not be the same from project to project.  Therefore we must develop a system to make a system.  By creating a system of templates, checklists, flow diagrams, and systems that are relatively easy to audit we have standardized the system that is used to identify and then implement quality measures and quality assurance.  These systems are created as modular work packages and wbs entries.  The PMO will establish that all projects must utilize this system for quality assurance.  The lessons learned from specific projects will also be stored so if there is an identical procedure being completed with similar thresholds and benchmarking standards then it may be used...

read more

Standardize Plan Procurements Process

Standardize Plan Procurements Process The standardization of the practices utilized to plan procurements are some of the most debated in the business arena.  It is seen as a place where there is a cash outflow and it appears to be immediate and without control.  Standardizing this process relies upon the decisions as to whether to buy or build, and if we will buy, as is usually the case, how will be evaluate and plan our procurements with outside organizations.  When deciding on make or buy of course our accounting/finance departments can all be called upon to determine what the prudent course of action may be.  Further it is possible that resources may be theoretically available, but are allocated to other projects.  The decision should be that which gives the greatest value to the organization.  This process can be standardized in qualitative and quantitative means.  Because it is possible to develop such a model it is important that this becomes a WBS modular component that is reused on future projects.  Once the system has been designed it will reside in the PMO and will be ready for use on future projects.  Perhaps as corporate thresholds change it will periodically be updated.  The idea of having outside vendors go through a vendor selection process can be something that really hampers the progress of a project.  Developing strategic partnerships with key procurement supply chain organizations will allow for a common set of metrics for quality and risk analysis.  This will allow for very expedient approval of the partner t provide the service at a predetermined rate.  An approved vendor would be the next level down and would require logistics as well as contracts to be developed, but would not require extensive investigation by legal and finance.  Finding a fresh new procurement supply chain devoid of partnerships or approved vendor lists quick eats away precious time from the project, and will cost money in the allocation of internal resources. Utilizing the supply chain as distinctive components of a vertically integrated wbs unveils the ability to create a standardized process when using strategic partners or approved vendors.  This process can be made into modular and reusable WBS entries that are stored in the PMO.  These entries are inclusive of the wbs dictionary entry describing the process. Detailing two processes in the standardization schema that of deciding whether to buy or build, and if the decision is made to buy who will we buy from.  It is important to have a quantitative and qualitative approach predesigned for the decision to buy or build.  It should be directed toward finance.  The qualitative analysis will develop the scale of importance for utilizing scarce resources available within the organization.  After this process has been standardized and made a part of the standard wbs the decision is made.  When there is a decision to buy there are a range of vendors available:  Strategic partners that have common and interrelated systems and require no prior approval to utilize as they have fully integrated their supply chain.  Approved vendors may also be used with the cautionary note that it will take more time to develop the logistics and finance, but a new contracting and bidding procedure will not need to take place.  Utilizing a new supply chain or new vendors will...

read more

Standardize Risk Identification Process

Standardize Risk Identification Process The process for understanding risk can be difficult to understand.  Risk is any change to the project plan the is either positive or negative.  Risks may be accepted, ignored, mitigated or transferred.  Transferring a risk is buying insurance or outsourcing the process to a contractor letting the carry the burden of the risk.  Mitigation of risks is developing a plan for what to do if the risk occurs, by understanding its impact, and what we would need to do if the risk were realized.  Ignoring a risk may occur when the risk will have limited impact of time, scope. Or budget. Accepting a risk when there is a high probability of it occurring allows the project manager to assume the risk will occur and include it in the project plan.  One question that can occur in this process is asking at what level of risk do I need to wake up the executive at 3:00AM. This is risk impact.  A P&I matrix is a tool that allows one to compare the relative impact and the relative probability of a risk occurring.  This matrix assigns scores from one to ten for each attribute.  Multiplying the scores will arrive at a probability and impact composite.  After determining which risks are the most demanding of the project one can decide what course of action would be prudent.  Each organization has it’s own risk threshold for time, scope, and budget variances.  It is best to involve the project sponsor or an executive in determining what level of identified lists would be acceptable. It is important for each work package listed in the WBS that there be an associated risk entry.  It should include it’s risk score, along with one of the categories of action for responding to a risk listed above.  The standardization of the process allows for the repeatability of many tasks that are shared among projects. That will most likely have the same or similar risk categories and responses that have had in previous projects.  Gathering information from lessons learned and from subject matter experts will allow for the best risk identification, remembering that we need to confirm our organization’s thresholds.  Creating a standardized form with checklist is advisable so that each WBS entry is examined for risk, and it’s identification.  Looking at the assumptions we have about how a process will proceed can be a paradigm shift when someone else who will actually be doing the work examines the risk assessment.  In addition to the P&I Matrix, flow charts and cause and effect diagramming can unravel risks quickly.  Understanding how to always look at each entry in the WBS ad then carefully analyzing the risk through the processes above each time will do two things.  First it will allow you to have a rich database of predetermined risks for repeated work packages.   By doing this you will have repeatability saving the time necessary to reinvent the wheel for every project.  It will also allows for the best and most prudent decision to be made.  Always going through the same process:  first examining the WBS and comparing it to the PMO’s listing of WBS work package entries, add these to your project.   Second consult experts who have done similar work for their evaluation of risk.  Use the...

read more

Standardize Project Plan Communications Process

Standardize Project Plan Communications Process         OPM3 BP ID: 1170 Blog post#22, David P. Cahill III Risks are identified so that they may be mitigated in the proper fashion.  By definition risks may be positive or negative.  It is important to construct risks for each work package identified in the WBS.  Risks are identified and a decision is made to exploit, transfer, avoid, or accept each risk.  There may be multiple risks per work package.  Many processes are repeated across projects, especially within a common program.  These WBS entries that are standardized should identify each associated risk.  The risk management plan will identify how the risks will be handled.  Transference of risk is buying insurance, surety bonds, or using resources outside of the organization to complete the task.  Acceptance of the risk updates the project plan to include necessary activities to mitigate the risk.  There will be risks to time, scope, and budget, and will be part of the plans associated to each, as recorded for each WBS entry.  Stakeholders assigned to the work package may be assigned to activities if the risk is realized, or these may be transferred to a risk management team in the organization – in either case this should be noted in the WBS number record.  The quality plan may list ways of testing for the risk to determine if it has been realized, these benchmarks should be noted in the entry.  Cost and schedule changes that may be realized should also be identified as a part of this process. A review of the cost and time management plans as well as the scope baseline will need to be done in order to identify the extent of each risk given its mitigation strategy.  Team brainstorming can be an effective way of identifying risks, there is the danger of the bandwagon effect when doing informal brainstorming, formal brainstorming has this effect reduced, whereas the Delphi technique eliminates it.  Common risks that have been identified for common WBS entries by the PMO will be used in place of these techniques across projects.  Developing checklists that will help determine what leads to the realization of these risks is an excellent form of risk quality control.  These checklists should be appened to the work package and used in an iterative fashion throughout the project – used as necessary and updated throughout the project.  Once risks have been identified there should be an analysis of the assumptions leading to that risk.  Then risks and their mitigation strategies can be more effectively identified.  Ishikawa diagrams help in the process of determining the cause and effect of various risks, and are standardized for all risks that are identified to better determine mitigation strategies.  Process charts can be used to determine the ripple effect of the risk throughout the project.  A SWOT analysis can be helpful in identifying overlying factors that may cause realized risks in the organization.  Lessons learned from previous projects, SME’s, and risk teams may be of use for finalizing the risk for each work package, and its associated mitigation strategy.  A risk register should be created that corresponds risks to the WBS entries and the stakeholder registers.  An owner should be assigned to each risk.  The register is an update for the entire WBS dictionary with all other...

read more

Standardize Project Plan Communications Process

Standardize Project Plan Communications Process OPM3 BP ID: 1160 Blog post#21, David P. Cahill III This process can be standardized by applying to each work package listed in the WBS a reporting and collaboration tag. Such a tag will allow you to see who will be working on the project, who will report on the project, and who will be reported to, and the frequency. Although PMBOK doesn’t list it I find that a RACI should be done for each work package and the communications channels can be more defined than simply using the inputs of the stakeholder register and the stakeholder management plan. When each work package is broken down it should be noted if there are any reporting requirements for regulatory reasons, and how these will be archived. Additionally many PMIS software packages will integrate and plan communications. This method of planned reporting and collaboration is tied to communications systems – usually e-mail, and works with enterprise wide PMIS software systems. Setting the system with MS Outlook would not be difficult. Remembering that according to PMBO the number of communication channels including ad hoc communications is n(n-1)/2 there are an amazing number of ways that things can be communicated throughout a project. This is why an org-chart within the project can be important and used to communicate up rather than sideways. Making mandatory communications sufficient for all project needs is not practical, but there need to be standards in how many people are included in e-mail memos, conversations, or reports and why certain team members would be excluded. Determining who will communicate with whom is as important as determining who will not communicate with who officially. Communicating with the legal department about any requirements for communication to be in paper form, archived, or submitted for official reporting. The technology used as mentioned earlier may be a true PMIS that is adequate or a work around to save money. Either way the PMIS should be administered by the PMO and define adequate and standardized methods for communication. Because each WBS entry will have a RACI attached to it there will be communication channels for those: responsible, accountable, consulted, and informed. It is important that the PMO assigns standards for communication to each role. In processes that are repeated in many WBS’s there is a need to have the roles of the individuals assigned as job titles that will fit the standardized process. These standardized roles may be such things as: Sponsor, Project Manager, Business Analyst, etc. The style of reporting and who is included expands to the actual project team and the system is created for accurate and informed communication. Communications systems include the PMIS model. The PMIS Model if Microsoft for example utilizes SharePoint, Out Look, and Access. Oracle, Sap, Clarity, etc, all have their own methods for keeping track of and administering communication, shared files, and automated reporting. The PMO should standardize the use of the technology across projects, and require it to be used according to the WBS entries that are common, and those identified as a part of this process. It is important for this plan to be recorded. The communications plan is an output of appending the communications to each WBS entry. In the communications plan there should be a reference to each...

read more

Standardize Manage Project Team Process

Standardize Manage Project Team Process     OPM3 BP ID: 1155 Blog post#20, David P. Cahill III Standardization of the management process may come as a relief to some project managers who believe they are 100% technical administrators of a methodology; however, for most of us it seem bureaucratic and cumbersome when our soft skills need to be combined with a process.  The process will work and needs to be standardized to reduce the amount of time determining how to manage, rather than managing.  For every project, every WBS work package that has resources assigned to it must also have a management plan attached, and an other such plan attached to the record of the resource, both referencing the task code. The idea here is to have a standard way of tracking performance, a benchmark set with real goals, and real criteria upon which to evaluate the resource’s work.  This should be laid out as per the usage of the resource in the PM Plan to have a performance benchmark for each activity they complete, and provide a dashboard to the PM indicating level of performance.  After the PM receives the dashboard at an interval predetermined by the PMO (usually on a gradient scale depending on the length of the project lifecycle,)  the PM will provide feedback to the resource regarding their performance.  Any issues with performance or interactions with other resources will be recorded and added to the project file, as well as, their personnel record.  If after such a review it is deemed necessary to return the resource to the labor pool prior to the end of their assignment a change request will be issued.  Such change request, given equal amounts of billable dollars, will need to be approved by the PMO and the HR department.  If the costs will exceed that of the previous resource a change request would also be filed with the change control board.  The project management plan will indicate what will sets are required for which tasks.  After resources have been assigned they will be appended to the PM plan.  In many cases Myers-Briggs, and DiSC profiles will be available on the resources.  It may be advantageous to use these to predevelop a team dynamic, and determine who to provide work that does not require them to be an SME to.  There should always be a baseline set for each task that the resource is assigned to that should be clear in their mind, and clearly recorded on paper. All team members must understand their roles and their deadlines. The manager should have regular ad hoc discussions with the resources on their team to monitor their needs, and progression on their work.  There should be determined status reporting dates where the resource will receive an appraisal of their performance.  These dates should be determined by the PMO and will vary in frequency with project length.  These meetings will be 360 review type of meetings covering team dynamics, technical performance, and conflict management.  If there is a major problem with a resource it must be recorded in the issues log and copied to the PMO, who may forward it to HR.  All serious issues will be added to the personnel file of the resource by the HR department, from the issues log.  The manager...

read more