Change Mangement Items to Add to Project Plan

1      Project Change Management Plan

1.1   Change Management Approach

Every project experiences change. If change is not formally managed, there is little likelihood that a project will be completed on time and within budget. Change can affect a project’s scope, cost, quality, risk, schedule, and work products, as well as the functioning of the project team.

The IT Monitoring & Enterprise Alert – Recommend Architecture & Tools Project will adopt a collaborative change management approach emphasizing an understanding and agreement among all parties about what the project changes are and how they will be managed.

When the project team needs to determine whether there is a change, the baseline documents are always the reference point. The baseline document for this phase of the project will be this document, the “Project Definition” document. Anything that is not covered in the baseline or that alters the baseline is a change. The process allows for change during the project life cycle, but puts the change in the context of the latest documented agreement.

1.2   Types of Change

Change will be classified as either design change or non-discretionary change. Non-discretionary change results from a failure of someone to do what he/she previously committed to, or the failure of some previously planned event to occur, and is sometimes tracked as lost time. A design change is an enhancement/correction to the system after initial specifications have been approved.

1.3   Change Budget

The purpose of the change budget is to provide an appropriation (of dollars and/or hours) that a project can draw from when change is encountered. The Project Team manages the change budget, providing approval for change expenditures when a change is approved or denying change expenditures when a change is deferred or rejected.

1.4   Change Management Process

The project team will manage changes by using the process described in this subsection.

1.4.1 Submit Change Request

Any team member may submit a written change request to the Project Manager.  

1.4.2 Perform a Preliminary Evaluation

The Project Manager reviews each change request and determines whether to defer, reject, or accept the change. If the change is accepted, the Project Manager estimates the effort to perform the impact analysis. Because an impact analysis of significant effort can cause a change to the current project schedule and/or budget, the client must decide whether to move to impact analysis.

1.4.3 Analyze Impact

If the change is to undergo an impact analysis, the Project Manager will assign the change request to a project team member. For our project, simple technical implementation, the technical team assumes responsibility for the impact analysis and involves additional technical staff as necessary.

The assigned resource(s) and the Project Manager first review the estimate for the effort of the impact analysis, and then work together to determine the effort, cost, schedule, and resources needed to implement the proposed change.

1.4.4 Review and Implement the Change

The Project Manager submits the impact analysis report to Project Sponsors for review.

¨       If the change is approved, the appropriate processes are followed to update the work plan, project documents, and the change is implemented. 

¨       If the change is rejected, the Project Manager logs the decision and reason and closes the change request.

¨       If the change is deferred, the date for the next review is set.

1.5   Roles for Change Management

Role (Contact Name)	Role
Project Manager	Receives change requests
Project Core Team	Performs preliminary evaluation
Project Sponsors	Final authority to approve a change for implementation

Starting the Project out Right

First – make sure all stakeholders are at the first meeting. Also ask the Project Sponsor to tell everyone you are the Project Manager (transferring authority). Talk about the processes you will use and the communication everyone can excpect from you.

Once you have a definitive scope, write a requriements document to meet that scope and distriubute it and sign it off. After this point, any change in scope should go through  your defined scope mamangement process.

Do your schedule as a team and construct a Work Breakdown Structure. Break each task down until it is no more than 40 hours or less. Add them back up to get the schedule. If management doesn’t want the date you’ve come up with ask them which scope they want to drop. Remind them that each feature takes time from you (as PM), the coder, the tester, the documenter and suppport.

As you move from requirements to specifications and coding, adding scope is even more costly. It disrupts everyone. Try to put it in a subsequent release.

Above all, make sure you communicate schedule, risks and status very frequently; and hopefully have a team site on SharePoint that everyone can see.

Scope Creep

People have asked me how to stop scopr creep. The way I do it is to have a change review board that every scope change must go through to be reviewd. That usually stops the managers from adding scope since I ask theym to sign off on the change management board in the beginning.

The decond problem id when and engineer wants to add scope on his own. To stop that, I have team members put in their time daily and their remaining time to get a task done. That helps me to find potential scope creep.

It is also vital to explain the whole process to the team and stakeholders. No one really wants the projct to fail and when they realize the impact of adding a little code enhancement to the testing and documentation groups, they tend to stay away from it.

That being said, it is a #1 problem in Project Management. Just keep on top of the project at all times.

How to Write a Business Case

Most of us have had to write a Return on Investment or a Business Case for projects we have worked on. The purpose of these documents is to define the overall benefits and costs of a project at a very high level usually aimed at Project Sponsors. The document allows you to provide much more diligence on the costs and benefits, while still not requiring you to actually go through the effort of specifying the work at this time. All Software Projects go through iterations of detail definition as more is known about the project. They key is to set the expectation of the degree of schedule confidence at each level of specification. At the Business Case Level the confidence in the schedule is very low.

When the Business Case is accepted by the Project Sponsor it is time to write a Project Charter and Project Scope Document which can be used to finalize the Project Plan and Work Breakdown Structure.  It is ideal to have the project team identified once the Business Case is accepted. If not, it is vital to have the majority of them identified by the time you finalize the Project Plan, Work Breakdown Structure and Schedule.A feasibility study is used to provide much more diligence and understanding about whether the project is feasible or not. In fact, the feasibility study might be a project in itself. The study might just be a more detailed analysis of the viability of a project and may not require a small project structure.

The result of the feasibility study is a document that is also called a Feasibility Study. There are a number of areas of feasibility that should be analyzed.

• Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.
• Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.
• Operational. You should make sure that you have the ability to run the products that are built by the project. It is possible that the project itself is feasible, but you may have significant risk in being able to operate the product after the project is over.
• Geographic. Is the project feasible given the physical location of the project team?
• Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project. .
• Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?
• Cost/benefit analysis (high level). You still have to complete the cost/benefit analysis as a part of the feasibility study.
• Recommendations. The conclusions and recommendations should be noted. One technique that can be used is to look at a number of alternatives for how the project should progress (if at all). For each alternative discuss the benefits, costs and risks. This will show the reader that the right level of diligence was performed and that a number of alternatives were considered. Your final recommendation should address assumptions, risks, ROI (return on investment), estimated cost (with a confidence factor that is fairly low), priority and next steps to be performed.

All of this information provides further detail on the nature of your study and provides your management stakeholders with the complete set of information they need to make the best decision on how to proceed.

Linkedin Profile

Check out my Linkdin Profile at www.linkedin.com/in/dritter5!  I’d love to hear your comments on what services you would like provided.

 

Donna

Ways to remain calm during the PMP test

Make sure you have studied a lot. The test is a 4 hour multiple choice test that is randomly selected from PMI’s test base. Bring energy bars and water. They won’t let you take anything in, but will give you a locker to store your stuff. Take a break at least once an hour to stretch your legs, take a snack and break. This clears your head.

When you first get in the testing center, they give you paper and pencil. The first part of the test is a tutorial on how to take the test. Take this time to do a brain dump of all the formulas, knowlege areas and procces groups. The questions are very situational, so you can usually emliminate 2 answers quickly. If you are not sure, mark the question (it lets you do that to come back to it) and go on. Also, somethims questions further on into the test will help answer an earler question. Aim for 30 minutes for looking at the questions you didn’t feel sure about and to review your exam. THen as soo as you push the confirtm question, it will take a few minutes to grade (a long few minutes) but it will help a lot. I wasn’t sure I passed – but I made a 98%! Keep you PMP certifcation eu to date and you’ll never have to take the test again. When I took it, the rule was you had to get 60  PDUs in 3 years. You can get some from training or some from running projects, reading a new PM theory book and other things. Look on PMP.ORG to find out the requirements to keep your PMP certication. And get a good nights rest and calm yourself. No one knows what you make and I think they give you 2 or 3 times to pass.

 

Have a great day!

Donna

Developing a Project Scope Document

 

 

                        Developing a Project Scope Statement

 

The project scope statement is the definition of the project—what needs to be accomplished. The Develop Preliminary Project Scope Statement process addresses and documents the characteristics and boundaries of the project and its associated products and services, as well as the methods of acceptance and scope control. A project scope statement includes:

 

·         Project and product objectives

·         Product or service requirements and characteristics

·         Product acceptance criteria

·         Project boundaries

·         Project requirements and deliverables

·         Project constraints

·         Project assumptions

·         Initial project organization

·         Initial defined risks

·         Schedule milestones

·         Initial WBS

·         Order of magnitude cost estimate

·         Project configuration management requirements

·         Approval requirements

 

The preliminary project scope statement is developed from information provided by the initiator or sponsor. The project management team in the Scope Definition process further refines the preliminary project scope statement into the project scope statement. The project scope statement content will vary depending upon the application area and complexity of the project and can include some or all of the components identified above. During subsequent phases of multi-phase projects, the Develop Preliminary Project Scope Statement process validates and refines, if required, the project scope defined for that phase.

 

Project Scope Development Tools and Techniques

1 – Project Management Methodology

The project management methodology defines a process that aids a project  management team in developing and controlling changes to the preliminary project scope statement.

 

2 – Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of a preliminary project scope statement, facilitate feedback as the document is refined, control changes to the project scope statement, and release the approved document.

 

3 – Expert Judgment

Expert judgment is applied to any technical and management details to be included in the preliminary project scope statement.

         

Develop Project Plan

 

The Develop Project Management Plan process includes the actions necessary to define, integrate, and coordinate all subsidiary plans into a project management plan. The project management plan content will vary depending upon the application area and complexity of the project. This process results in a project management plan that is updated and revised through the Integrated Change Control process. The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan documents the collection of outputs of the planning processes of the Planning Process Group and includes:

 

·         The project management processes selected by the project management team

·         The level of implementation of each selected process

·         The descriptions of the tools and techniques to be used for accomplishing those processes

·         How the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes, and the essential inputs and outputs

·         How work will be executed to accomplish the project objectives

·         How changes will be monitored and controlled

·         How configuration management will be performed

·         How integrity of the performance measurement baselines will be maintained and used

·         The need and techniques for communication among stakeholders

·         The selected project life cycle and, for multi-phase projects, the associated project phases

·         Key management reviews for content, extent, and timing to facilitate addressing open issues and pending decisions.

 

The project management plan can be either summary level or detailed, and can be composed of one or more subsidiary plans and other components. Each of the subsidiary plans and components is detailed to the extent required by the specific project. These subsidiary plans include, but are not limited to:

 

·         Project scope management plan

·         Schedule management plan

·         Cost management plan

·         Quality management plan

·         Process improvement plan

·         Staffing management plan

·         Communication management plan

·         Risk management plan

·         Procurement management plan

 

These other components include, but are not limited to:

 

·         Milestone list

·         Resource calendar

·         Schedule baseline

·         Cost baseline

·         Quality baseline

·         Risk register

 

          Project Plan Tools and Techniques

Project Management Methodology

The project management methodology defines a process, which aids a project management team in developing and controlling changes to the project management plan.

 

Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of the project management plan, facilitate feedback as the document is developed, control changes to the project management plan, and release the approved document.

 

·         Configuration Management System The configuration management system is a subsystem of the overall project management information system. The system includes the process for submitting proposed changes, tracking systems for reviewing and approving proposed changes, defining approval levels for authorizing changes, and providing a method to validate approved changes. In most application areas, the configuration management system includes the change control system. The configuration management system is also a collection of formal documented procedures used to apply technical and administrative direction and surveillance to:

o   Identify and document the functional and physical characteristics of a product or component

o   Control any changes to such characteristics

o   Record and report each change and its implementation status

o   Support the audit of the products or components to verify conformance to requirements.

 

·         Change Control System The change control system is a collection of formal documented procedures that define how project deliverables and documentation are controlled, changed, and approved. The change control system is a subsystem of the configuration management system. For example, for information technology systems, a change control system can include the specifications (scripts, source code, data definition language, etc.) for each software component.

 

·         Expert Judgment Expert judgment is applied to develop technical and management details to be included in the project management plan.

 

 

Developing the Scope Statement and Project Plan

 

 

                        Developing a Project Scope Statement

 

The project scope statement is the definition of the project—what needs to be accomplished. The Develop Preliminary Project Scope Statement process addresses and documents the characteristics and boundaries of the project and its associated products and services, as well as the methods of acceptance and scope control. A project scope statement includes:

 

·         Project and product objectives

·         Product or service requirements and characteristics

·         Product acceptance criteria

·         Project boundaries

·         Project requirements and deliverables

·         Project constraints

·         Project assumptions

·         Initial project organization

·         Initial defined risks

·         Schedule milestones

·         Initial WBS

·         Order of magnitude cost estimate

·         Project configuration management requirements

·         Approval requirements

 

The preliminary project scope statement is developed from information provided by the initiator or sponsor. The project management team in the Scope Definition process further refines the preliminary project scope statement into the project scope statement. The project scope statement content will vary depending upon the application area and complexity of the project and can include some or all of the components identified above. During subsequent phases of multi-phase projects, the Develop Preliminary Project Scope Statement process validates and refines, if required, the project scope defined for that phase.

 

Project Scope Development Tools and Techniques

1 – Project Management Methodology

The project management methodology defines a process that aids a project  management team in developing and controlling changes to the preliminary project scope statement.

 

2 – Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of a preliminary project scope statement, facilitate feedback as the document is refined, control changes to the project scope statement, and release the approved document.

 

3 – Expert Judgment

Expert judgment is applied to any technical and management details to be included in the preliminary project scope statement.

         

Develop Project Plan

 

The Develop Project Management Plan process includes the actions necessary to define, integrate, and coordinate all subsidiary plans into a project management plan. The project management plan content will vary depending upon the application area and complexity of the project. This process results in a project management plan that is updated and revised through the Integrated Change Control process. The project management plan defines how the project is executed, monitored and controlled, and closed. The project management plan documents the collection of outputs of the planning processes of the Planning Process Group and includes:

 

·         The project management processes selected by the project management team

·         The level of implementation of each selected process

·         The descriptions of the tools and techniques to be used for accomplishing those processes

·         How the selected processes will be used to manage the specific project, including the dependencies and interactions among those processes, and the essential inputs and outputs

·         How work will be executed to accomplish the project objectives

·         How changes will be monitored and controlled

·         How configuration management will be performed

·         How integrity of the performance measurement baselines will be maintained and used

·         The need and techniques for communication among stakeholders

·         The selected project life cycle and, for multi-phase projects, the associated project phases

·         Key management reviews for content, extent, and timing to facilitate addressing open issues and pending decisions.

 

The project management plan can be either summary level or detailed, and can be composed of one or more subsidiary plans and other components. Each of the subsidiary plans and components is detailed to the extent required by the specific project. These subsidiary plans include, but are not limited to:

 

·         Project scope management plan

·         Schedule management plan

·         Cost management plan

·         Quality management plan

·         Process improvement plan

·         Staffing management plan

·         Communication management plan

·         Risk management plan

·         Procurement management plan

 

These other components include, but are not limited to:

 

·         Milestone list

·         Resource calendar

·         Schedule baseline

·         Cost baseline

·         Quality baseline

·         Risk register

 

          Project Plan Tools and Techniques

Project Management Methodology

The project management methodology defines a process, which aids a project management team in developing and controlling changes to the project management plan.

 

Project Management Information System

The project management information system, an automated system, is used by the project management team to support generation of the project management plan, facilitate feedback as the document is developed, control changes to the project management plan, and release the approved document.

 

·         Configuration Management System The configuration management system is a subsystem of the overall project management information system. The system includes the process for submitting proposed changes, tracking systems for reviewing and approving proposed changes, defining approval levels for authorizing changes, and providing a method to validate approved changes. In most application areas, the configuration management system includes the change control system. The configuration management system is also a collection of formal documented procedures used to apply technical and administrative direction and surveillance to:

o   Identify and document the functional and physical characteristics of a product or component

o   Control any changes to such characteristics

o   Record and report each change and its implementation status

o   Support the audit of the products or components to verify conformance to requirements.

 

·         Change Control System The change control system is a collection of formal documented procedures that define how project deliverables and documentation are controlled, changed, and approved. The change control system is a subsystem of the configuration management system. For example, for information technology systems, a change control system can include the specifications (scripts, source code, data definition language, etc.) for each software component.

 

·         Expert Judgment Expert judgment is applied to develop technical and management details to be included in the project management plan.

 

 

 

---

[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

How to Write a Project Charter

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning (if possible) and preferably while the project charter is being developed.

 

In my experience this is not always possible, but I highly recommend that you follow this and as the very least, as soon as you (or someone else) is assigned as the Project Manager, draft this document and have it signed off by the stakeholders.

 

A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, should issue the project charter. Projects are usually chartered and authorized external to the project organization by an enterprise, a government agency, a company, a program organization, or a portfolio organization, as a result of one or more of the following:

 

·         A market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages)

·         A business need (e.g., a training company authorizing a project to create a new course to increase its revenues)

·         A customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park)

·         A technological advance (e.g., an electronics firm authorizing a new project to develop a faster, cheaper, and smaller laptop after advances in computer memory and electronics technology)

·         A legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials)

·         A social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).

 

These stimuli can also be called problems, opportunities, or business requirements. The central theme of all these stimuli is that management must make a decision about how to respond and what projects to authorize and charter.

 

Make sure to have these requirements documented and signed off as they will be used to create the Project Scope Document.

 

Project selection methods involve measuring value or attractiveness to the project owner or sponsor and may include other organizational decision criteria. Project selection also applies to choosing alternative ways of executing the project.

 

Chartering a project links the project to the ongoing work of the organization. In some organizations, a project is not formally chartered and initiated until completion of a needs assessment, feasibility study, preliminary plan, or some other equivalent form of analysis that was separately initiated.

 

Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, service, or result that is intended to satisfy those requirements. The project charter, either directly, or by reference to other documents, should address the following information:

 

·        Requirements that satisfy customer, sponsor, and other stakeholder needs, wants and expectations

·        Business needs, high-level project description, or product requirements that the project is undertaken to address

·        Project purpose or justification

·        Assigned Project Manager and authority level

·        Summary milestone schedule

·        Stakeholder influences

·        Functional organizations and their participation

·        Organizational, environmental and external assumptions

·        Organizational, environmental and external constraints

·        Business case justifying the project, including return on investment

·        Summary budget.

 

During subsequent phases of multi-phase projects, the Develop Project

Charter process validates the decisions made during the original chartering of the project. If required, it also authorizes the next project phase, and updates the charter.

 

Inputs:

Contract (When Applicable)

A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.

 

Project Statement of Work

 

The statement of work (SOW) is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. The SOW indicates a:

 

·        Business need – an organization’s business need can be based on needed training, market demand, technological advance, legal requirement, or governmental standard.

·        Product scope description – documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes, as the product characteristics are progressively elaborated. These requirements should also document the relationship among the products or services being created and the business need or other stimulus that causes the need. While the form and substance of the product requirements document will vary, it should always be detailed enough to support later project planning.

·        Strategic plan – all projects should support the organization’s strategic goals. The strategic plan of the performing organization should be considered as a factor when making project selection decisions.

 

Enterprise Environmental Factors

 

When developing the project charter, any and all of the organization’s enterprise environmental factors and systems that surround and influence the project’s success must be considered. This includes items such as, but not limited to:

 

·        Organizational or company culture and structure

·        Governmental or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards)

·        Infrastructure (e.g., existing facilities and capital equipment)

·        Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing)

·        Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records)

·        Company work authorization system

·        Marketplace conditions

·        Stakeholder risk tolerances

·        Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases)

·        Project management information systems (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems).

 

Organizational Process Assets

 

When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project’s success can be drawn from organizational process assets. Any and all of the organizations involved in the project can have formal and informal policies, procedures, plans, and guidelines whose effects must be considered. Organizational process assets also represent the organizations’ learning and knowledge from previous projects; for example, completed schedules, risk data, and earned value data. Organizational process assets can be organized differently, depending on the type of industry, organization, and application area. For example, the organizational process assets could be grouped into two categories:

 

·         Organization’s processes and procedures for conducting work:

o    Organizational standard processes, such as standards, policies (e.g., safety and health policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization)

o    Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria

o    Templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

o     Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project

o     Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention, and security requirements)

o     Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria)

o    Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions)

o     Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking

o     Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated

o     Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

·        Procedures for approving and issuing work authorizations. Organizational corporate knowledge base for storing and retrieving information:

o     Process measurement database used to collect and make available measurement data on processes and products

o     Project files (e.g., scope, cost, schedule, and quality baselines, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact)

o    Historical information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort) and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

o     Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents

o     Financial database containing information such as labor hours, incurred costs, budgets, and any project cost overruns.

 

Develop Project Charter: Tools and Techniques

 

Project Selection Methods

Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories:

 

·        Benefit measurement methods that are comparative approaches, scoring models, benefit contribution, or economic models.

·        Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.

 

Project Management Methodology

 

A project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. A project management methodology may or may not be an elaboration of a project management standard. A project management methodology can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.

 

Project Management Information System

 

The Project Management Information System (PMIS) is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is refined, control changes to the project charter, and release the approved document.

 

Expert Judgment

 

Expert judgment is often used to assess the inputs needed to develop the project charter. You will see this technique used in many of the Project Processes. Such judgment and expertise is applied to any technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including:

 

·         Other units within the organization

·         Consultants

·         Stakeholders, including customers or sponsors

·         Professional and technical associations

·         Industry groups.[i]

 

 

[i]  2007 Project Management Institute, Four Campus Blvd., Newton Square, PA 17903

---

Project Process Groups

There are five Process Groups defined by PMI. They have clear dependencies and are performed in the same sequence on each project. They are independent of application areas or industry focus. Individual Process Groups and individual constituent processes are often iterated prior to completing the project. Constituent processes also can have interactions both within a Process Group and among Process Groups.

 

Note: During project phases, if a change occurs during the project execution or control, the documents and tools used in the Process groups may have to be revisited. For example, if a change is made to the scope during the project execution phase, the scope document and all of the project plans must be revisited to include the new scope.

 

An individual process may define and constrain how inputs are used to produce outputs for that Process Group. They are defined in a way that projects of all kinds can be managed with this standard, so some inputs or outputs may not be relevant to every project.

 

A Process Group includes the constituent project management processes that are linked by the respective inputs and outputs, that is, the result or outcome of one process becomes the input to another. The Monitoring and Controlling Process Group, for example, not only monitors and controls the work being done during a Process Group, but also monitors and controls the entire project effort. The Monitoring and Controlling Process Group must also provide feedback to implement corrective or preventive actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan. Many additional interactions among the Process Groups are likely.

 

Where large or complex projects may be separated into distinct phases or sub-projects such as feasibility study, concept development, design, prototype, build, test, etc. all of the Process Group processes would normally be repeated for each phase or subproject.

The five Process Groups are:

 

·         Initiating Process Group. Defines and authorizes the project or a project.

·         Planning Process Group. Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address.

·         Executing Process Group. Integrates people and other resources to carry out the project management plan for the project.

·         Monitoring and Controlling Process Group. Regularly measures and monitors progress to identify variances from the project management plan so that corrective action can be taken when necessary to meet project objectives.

·         Closing Process Group. Formalizes acceptance of the product, service or result and brings the project or a project phase to an orderly end.