Project Management

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

August 28, 2009 Posted by | PMP, Project Initiation, Scope Management | 2 Comments

Scope Change Control

Who hasn’t been on a project where scope creep is an issue? One of my pet peeves is when people try to add functionality (or even a bug fix) and don’t realize they need to inform the Project Manager and all prior documentation has to be changed. An engineer may be able to code a fix very quickly, but if he does that has ramifications on documentation, schedule management and quality control (to name a few). When someone tries to pull this, I always draw the infamous triangle of scope, time/cost and resources. If one changes, the others will as well.

One way to formally control this is to implement a formal scope verification process where you require a change to be communicated to the stakeholders’ for formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. If the project is terminated early, the project scope verification process should establish and document the level and extent of completion.

Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables.

Quality control is generally performed before scope verification, but these two processes can be performed in parallel; and when a change occurs (that is accepted) all project team members need to re-examine their project documents and schedule. Any corrective changes go to the project manager and new plans and schedules are produced. Then a process of verifying the scope occurs. The following lists potential outputs from Scope verification:

  1. Accepted Deliverables: The Scope Verification process documents those completed deliverables that have been accepted. Those completed deliverables that have not been accepted are documented, along with the reasons for non-acceptance. Scope verification includes supporting documentation received from the customer or sponsor and acknowledging stakeholder acceptance of the project’s deliverables.
  2. Requested Changes; Requested changes may be generated from the Scope Verification process, and are processed for review and disposition through the Integrated Change Control processes.
  3. Recommended Corrective Actions

For a successful project, the Project Manager is in charge of scope control. Scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process. The biggest thing to remember is to communicate to all team members and stake holders during this process. It is wise to institute a formal change control system.

A project scope change control system, documented in the project scope management plan, defines the procedures by which the project scope and product scope can be changed. The system includes the documentation, tracking systems, and approval levels necessary for authorizing changes. The scope change control system is integrated with any overall project management information system to control project scope. When the project is managed under a contract, the change control system also complies with all relevant contractual provisions.

Project performance measurements are used to assess the magnitude of variation. Important aspects of project scope control include determining the cause of variance relative to the scope baseline and deciding whether corrective action is required. Earned value management is very helpful here. Approved change requests affecting the project scope can require modifications to the WBS and WBS dictionary, the project scope statement, and the project scope management plan. These approved change requests can cause updates to components of the project management plan.

A formal configuration management system provides procedures for the status of the deliverables, and assures that requested changes to the project scope and product scope are thoroughly considered and documented before being processed through the Integrated Change Control process.

 

January 19, 2009 Posted by | Project Management, Schedule Management, Scope Management | 3 Comments

Building a Work Breakdown Structure

 

Building a Work Breakdown Structure

The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled.

 

On projects I’ve worked on, the project team would go into a conference room and use post it notes for each piece of work until we reached something that was a week or less. NOTE: It’s easiest to bring a roll of paper to put the post it notes on so you can roll the whole thing up to input it into soft format.

 

The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project.

 

Work Breakdown Structure Templates

 

Although each project is unique, a WBS from a previous project can often be used as a template for a new project, since some projects will resemble another prior project to some extent. For example, most projects within a given organization will have the same or similar project life cycles and, therefore, have the same or similar deliverables required from each phase. Many application areas or performing organizations have standard WBS templates.

 

The Project Management Institute Practice Standard for Work Breakdown Structures provides guidance for the generation, development, and application of work breakdown structures. This publication contains industry-specific examples of WBS templates that can be tailored to specific projects in a particular application area. A portion of a WBS example, with some branches of the WBS decomposed down through the work package level.

 

Decomposition

 

Decomposition is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level. The work package level is the lowest level in the WBS, and is the point at which the cost and schedule for the work can be reliably estimated. The level of detail for work packages will vary with the size and complexity of the project.

 

Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.

 

Different deliverables can have different levels of decomposition. To arrive at a manageable work effort (i.e., a work package), the work for some deliverables needs to be decomposed only to the next level, while others need more levels of decomposition. As the work is decomposed to lower levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work. The project team needs to seek a balance between too little and too much in the level of WBS planning detail.

5

Decomposition of the total project work generally involves the following activities:

 

·         Identifying the deliverables and related work

·         Structuring and organizing the WBS

·         Decomposing the upper WBS levels into lower level detailed components

·         Developing and assigning identification codes to the WBS components

·         Verifying that the degree of decomposition of the work is necessary and sufficient.

 

This analysis requires a degree of expert judgment to identify all the work including project management deliverables and those deliverables required by contract. Structuring and organizing the deliverables and associated project work into a WBS that can meet the control and management requirements of the project management team is an analytical technique that may be done with the use of a WBS template. The resulting structure can take a number of forms, such as:

 

·         Using the major deliverables and subprojects as the first level of decomposition.

·         Using subprojects where the subprojects may be developed by organizations outside the project team. For example, in some application areas, the project WBS can be defined and developed in multiple parts, such as a project summary WBS with multiple subprojects within the WBS that can be contracted out. The seller then develops the supporting contract work breakdown structure as part of the contracted work.

·         Using the phases of the project life cycle as the first level of decomposition, with the project deliverables inserted at the second level.

·         Using different approaches within each branch of the WBS, where test and evaluation is a phase, the air vehicle is a product, and training is a supporting service.

 

Decomposition of the upper level WBS components requires subdividing the work for each of the deliverables or subprojects into its fundamental components, where the WBS components represent verifiable products, services, or results. Each component should be clearly and completely defined and assigned to a specific performing organizational unit that accepts responsibility for the WBS component’s completion. The components are defined in terms of how the work of the project will actually be executed and controlled. For example, the status reporting component of project management could include weekly status reports, while a product to be manufactured might include several individual physical components plus the final assembly.

 

Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables.

 

Outputs of Creating a WBS:

 

·         Project Scope Statement (Updates): If approved change requests result from the Create WBS process, then the project scope statement is updated to include those approved changes.

·         Work Breakdown Structure: The key document generated by the Create WBS process is the actual WBS. Each WBS component, including work package and control accounts within a WBS, is generally assigned a unique identifier from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information.

 

The WBS should not be confused with other kinds of breakdown structures used to present project information. Other structures used in some application areas or other Knowledge Areas include:

 

·         Organizational Breakdown Structure (OBS). Provides a hierarchically organized depiction of the project organization arranged so that the work packages can be related to the performing organizational units.

·         Bill of Materials (BOM). Presents a hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product.

·         Risk Breakdown Structure (RBS). A hierarchically organized depiction of the identified project risks arranged by risk category.

·         Resource Breakdown Structure (RBS). A hierarchically organized depiction of the resources by type to be used on the project.

 

The WBS Dictionary

 

The document generated by the Create WBS process that supports the WBS is called the WBS dictionary and is a companion document to the WBS. The detailed content of the components contained in a WBS, including work packages and control accounts, can be described in the WBS dictionary. For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones. Other information for a WBS component can include contract information, quality requirements, and technical references to facilitate performance of the work. Other information for a control account would be a charge number. Other information for a work package can include a list of associated schedule activities, resources required, and an estimate of cost. Each WBS component is cross-referenced, as appropriate, to other WBS components in the WBS dictionary.

 

The Scope Baseline

 

The approved detailed project scope statement and it’s associated

WBS and WBS dictionary are the scope baseline for the project. The next step is to estimate all of the work packages and create your baseline schedule.

 

January 11, 2009 Posted by | PMBOK, Project Management, Scope Management | , | 8 Comments

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.

 

 

December 23, 2008 Posted by | PMP, Scope Management | 1 Comment

Construtcing a Project Charter – the Beginning of the Project Scope

 

 

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, and preferably while the project charter is being developed.

 

A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, issues 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 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. 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.

 

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, application area. For example, the organizational process assets could be grouped into two categories:

 

 Organization’s processes and procedures for conducting work:

·    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)

·    Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

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

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

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

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

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

·    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

·    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:

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

·    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)

·    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)

·    Issue and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

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

·    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. 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.

 

October 23, 2008 Posted by | Project Initiation, Project Management, Scope Management | , , | Leave a comment

The Project From Hell

 

Problem

I know all of you have had a project from hell. Mine was a project that had 4 releases before I took it over, so I had no ability to pick my team. The team dynamics had gotten so bad, and the code was so buggy, that the sales people wouldn’t sell the product!

My approach

This is the approach I took. I interviewed everyone involved in the project and quickly found out that the main problem was the technical leader. No one liked working with him and he thought he was the God of engineering. The technical writer was ready to go to HR with a charge of sexual harassment. That I had to inform the VP of engineering and the VP of HR in case the charge was made real and we had a legal issue on our hands.

I also worked extensively with the technical leader in the areas of communications and relationship building. The two of us were able to work well together, but somehow he couldn’t translate it to the rest of the team. He didn’t even know when he committed something that would be taken the wrong way. Whenever that happened, I immediately gave him feedback in the hopes he would start to learn to recognize these situations before they incurred and change his behavior.

Using other eye’s to help

When that didn’t work, I brought in a consulting team to help us agree on a mission, goals, roles and how we would run meetings. I invited people from all disciplines; software engineering, technical documentation, first and second level support, sales, marketing, services and quality.

The meetings were heated but we all were able to come up with an agreeable way to run the project. When we had a 3 month checkup with our consulting team, we were not doing much better. It came to the point where one of the support members verbally abused me in public. I had to make a decision, so I told the technical leader that his expertise was needed as a technical guru, but that I was give the project lead role to someone else on the team. Things slowly became better. The project team met to decide how to make the product more supportable and profitable. (Upper level management was ready to cancel the project at this point). We came up with a plan to have the people who knew the code best to do a massive code review and pick the hot spots that had to be rewritten.

The technical leader ended up leaving because it was his complicated, uncommented code that was causing the most problems.

Great ending

But there was a good ending. I presented this plan to upper management (which would take us a year without releasing while we were rewriting the code) expecting them to reject it. When we got the go ahead – we knew failure was not an option.

We included the whole team to draft a set of metrics that the code had to pass and refused to release it until the key support personnel gave it the ok. One of my inputs to these metrics was constant communications to the point that we met every day to plan the next day’s activities. We won a prize within a year for raising sales so dramatically.

That was my hardest project, but we all learned a lot. My only regret was that I couldn’t save the technical leader. He was very brilliant, but refused to mentor anyone of the team. My message to you is there is no project that is impossible.

 Have a great day! Donna

October 6, 2008 Posted by | Communications Management, Project Management, Risk Management, Scope Management | , , | Leave a comment

What Goes Into a Project Plan?

What goes into a Project Plan?

1.   The Scope Management Plan: This is a document that defines the Scope of the Project. It is especially important to be though and accurate because it feeds into the Requirements document. It is also important that all the Stakeholders buy into it. It should be signed off before going the next step. If the Scope changes it has to go through a change management process and all of the Stakeholders must sign off on it.

2.   Schedule Management Plan: The Schedule Management Plan is a component part of the Project Plan that is use in Activity resource planning. The Activity resource plan includes expert judgment, various levels of resource levels or skills, size of machines, tools and make/buy decisions.

3.   Cost Management Plan: Costs will adhere to a prescribed precision based on the scope of the project and may include a contingency amount. Various cost measures or other indicators (e.g. person-days, volume of product).

4.   Quality Management Plan: The Quality Management Plan describes how the project team will implement the organization’s quality policy. It must address the quality control, quality management and continuous process improvement for the project.

5.   Staffing Management Plan: Identifying project roles, responsibilities and reporting relationships. Obtaining the human resources to complete the project. Improving the competencies and interaction of team members to enhance project performance. Team building plays a big part here.

6.   Communications Plan: Determining the information needs of the stakeholders. Making needed communications available to the stakeholders in a timely manner. Collecting and distributing performance information including status reports, performance reports and forecasting.

7.   Risk Management Plan: The Risk Management Plan includes risk identification, risk analysis, risk response planning, monitoring and control.

8.   The Procurement Plan: This plan includes what has to be procured, who will provide the estimates, types of contracts to be used, managing multiple providers, constraints and assumptions that could affect the contract and handling make/buy decisions. [i]


[i] 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

September 28, 2008 Posted by | Communications Management, PMP, Project Management, Risk Management, Scope Management | | Leave a comment

Work Breakdown Stuctures

Have you ever mapped out a family tree? Our family has done this for years tracing us back to Charlemagne. Genealogy is favorite habit started my Grandfather.

A work breakdown structure (WBS) is very similar to a family tree. It maps out the deliverables of the project, with sub deliverables and activities stemming in a tree format. One of my favorite ways to do the WBS is with yellow post it’s so you can move them around to where they belong. Once I worked on a project where we had to tape together all of the papers that included the post it’s and it was at least 25 pages. This served us well when we showed management the magnitude of the scope of the project!

Doing this on large sheets of paper is useful so you can capture the finished product. A Guide to the PMBOK describes a WBS this way: “A WBS is a deliverable oriented grouping of project components that organizes and defines the total scope of the project; work not defined in the WBS is outside of the project”.

A Work Breakdown Structure is break down the work packages to enable you to roll them back up to a schedule that is complete. A work package is usually no more than 40 hours.

The WBS should detail the full scope of work needed to complete the project. Accuracy and completeness are required when composing your WBS.

Decomposition is one of the tools you will use when preparing your WBS. You should be able to break down the deliverables to a point where you can easily plan, execute, control and close out the project deliverables. Each work package should be able to be easily estimated in the Activity Definition Process.

You can think of this process in 4 major steps:

1.    Identify all of the major deliverables. The PMBOK is clear on noting that the deliverables should be defined according to the way the project is organized. One way is to organize a project in phases. The phases become the first level of decomposition, followed by the deliverables.

2.    Step2 involves estimating cost and duration. If that cannot be done, then you have to decompose further until the work package can be estimated. I usually use a work package of 20-40 hours at the most. Not all deliverables will have the same level of decomposition. In any case, a schedule cannot be made until the WBS is complete and has estimates that are as accurate as possible.

3.    Step 3 involves identifying components that make up the deliverables.

4.    Step 4 is the verification step. You need to determine that each component listed is clear, complete and necessary to fulfill the requirements of the deliverable. Also, you need to easily add up all the estimates, budget and assignments to create a solid schedule.

A WBS looks very much like a flow chart. The goal is to break down the work so that each work package can be assigned to a specific person for accountability and the Project Manager can easily manage the schedule knowing that all parts of the project have been broken down to their smallest part.

Each Work package is assigned a unique identifier and these are documented in the WBS dictionary. The dictionary includes a description of the work package, costs, budgets, schedule dates, resource assignments and activity descriptions.

This process sounds like a lot of work, but it is a known fact that the more you plan, the better you will be in the end.  I like to use SharePoint to keep this document and keep for the project records.

The WBS plays a major part of Project Management. For those taking the PMP certification course, I was told that if you didn’t know the answer to a question WBS probably was it!

 

 

September 18, 2008 Posted by | Scope Management | , | Leave a comment

Scope Management

Scope Management is the process of defining what work is required and then making sure that all of the work and only the work is done. This Process includes scope planning, scope definition, creation of the Work Breakdown Structure (WBS), scope verification and scope control.

Any Project Manager will tell you that “scope creep”is one of the worst problems on a project. That means you must institute a formal Change Control mechanism. All scope must fit the Program’s charter (defined earlier in the process).

You should be giving the customer what he asked for; no more, no less. I heard someone once compare it to having a customer order a VW and the engineering team building a Cadillac. Giving away extras is a waste of time and adds to the risk of the project. Maybe it only takes 30 minutes to code; but what about testing, documentation, and training to name a few.

Scope Management involves mastering both product and project scope. Product Scope is another way to say “requirements that relate to the product of the project”. Project scope is the work you need to deliver that product.  This includes meetings, reports, analysis and any other project related activities.

Scope baseline: Measurements of success on the project include whether the requirements have been met and whether the scope baseline has been met. The scope baseline is the scope statement , the work breakdown structure and the work breakdown structure dictionary.

Scope planning is focused on thinking ahead and thinking “how will I do this” before doing the work and the Scope Management Plan.

The Scope Management Plan answers “how will I do scope? What tools should I use to plan how the project will accomplish the scope of this project?” The output of Scope Planning is the Project Scope Management Plan. It should contain 3 parts: how will the scope be planned, executed and controlled. It may be created in iterative steps during project planning. Once complete, it becomes part of the overall Project Plan and cannot be changed without going through a formal Change review process. Once you get to Risk Planning, it is possible that changes will have to be made to the Scope using the formal Change review process.

Scope definition: Scope definition is primarily concerned with what is and is not included in the project.  Scope definition takes into account constraints and assumptions. The result is used to manage and measure the project performance.

Stakeholder Analysis: This process makes sure the stakeholders’ needs are metm and turned into requirements.

Product Analysis: This analyzes the objectives stated by the customer or sponsor and turns them into tangible requirements.

Project Scope Statement: The preliminary scope statement is expanded into the “final” project scope statement to be used on the project. Different approaches to performing the work and incorporating the needs of the stakeholders are taken into consideration.

Scope planning inputs:

  • Product description
  • Project Charter
  • Project constraints
  • Project assumptions

The tools and techniques that may be used are benefit/cost analysis, expert judgement, product analysis and alternatives identification.

The main key message here is to have a clearly defined Change Management Plan to address any changes to the final scope. When a change is made, if it is deemed necessary, will cause many other plans and the schedule to be re-done. Changes should be documented as required, important, non-critical or nice to have.

 

 

Scope Management is the process of defining what work is required and then making sure that all of the work and only the work is done. This Process includes scope planning, scope defintion, creation of the Work Breakdown Structure (WBS), scope verification and scope control.

Any Project Manager will tell you that “scope creep”is one of the worst problems on a project. That means you must institute a formal Change Control mechanism. All scope must fit the Program’s charter (defined earlier in the process).

You should be giving the customer what he asked for; no more, no less. I heard someone once compare it to having a customer order a VW and the engineering team building a Cadillac. Giving away extras is a waste of time and adds to the risk of the project. Maybe it only takes 30 minutes to code; but what about testing, documentation, and training to name a few.

Scope Management involves mastering both product and project scope. Product Scope is another way to say “requirements that relate to the product of the project”. Project scope is the work you need to deliver that product.  This includes meetings, reports, analysis and any other project related activities.

Scope baseline: Measurements of success on the project include whether the requirements have been met and whether the scope baseline has been met. The scope baseline is the scope statement , the work breakdown structure and the work breakdown structure dictionary.

Scope planning is focused on thinking ahead and thinking “how will I do this” before doing the work and the Scope Management Plan.

The Scope Management Plan answers “how will I do scope? What tools should I use to plan how the project will accomplish the scope of this project?” The output of Scope Planning is the Project Scope Management Plan. It should contain 3 parts: how will the scope be planned, executed and controlled. It may be created in iterative steps during project planning. Once complete, it becomes part of the overall Project Plan and cannot be changed without going through a formal Change review process. Once you get to Risk Planning, it is possible that changes will have to be made to the Scope using the formal Change review process.

Scope definition: Scope definition is primarily concerned with what is and is not included in the project.  Scope definition takes into account constraints and assumptions. The result is used to manage and measure the project performance.

Stakeholder Analysis: This process makes sure the stakeholders’ needs are metm and turned into requirements.

Product Analysis: This analyzes the objectives stated by the customer or sponsor and turns them into tangible requirements.

Project Scope Statement: The preliminary scope statement is expanded into the “final” project scope statement to be used on the project. Different approaches to performing the work and incorporating the needs of the stakeholders are taken into consideration.

Scope planning inputs:

  • Product description
  • Project Charter
  • Project constraints
  • Project assumptions

The tools and techniques that may be used are benefit/cost analysis, expert judgement, product analysis and alternatives identification.

The main key message here is to have a clearly defined Change Management Plan to address any changes to the final scope. When a change is made, if it is deemed necessary, will cause many other plans and the schedule to be re-done. Changes should be documented as required, important, non-critical or nice to have.

 

 

September 17, 2008 Posted by | Scope Management | | Leave a comment

   

Follow

Get every new post delivered to your Inbox.

Join 80 other followers