Quality Guide - Welcome to Managing for Quality.
Here is a site that has some great information regarding Quality Management.
Thursday, July 29, 2004
Michael Greer's 20 PM Actions/Results
Michael Greer's 20 PM Actions/Results
This looks like a good site for general Project Management Information. Give it a try and let me know what you think.
This looks like a good site for general Project Management Information. Give it a try and let me know what you think.
Good Requirements Management = Increased ROI
What of the biggest areas of concern in the IT Project Management field is Requirements Management. It has been said that reducing requirements errors can have the biggest impact on delivering a quality software project on time and on budget. How do you as a Project Manager help to reduce requirements errors while not slowing down project progress?
Before we answer that question lets look at some industry statistics.
According to the Standish Group (over 352 companies reporting on over 8000 projects):
Before we answer that question lets look at some industry statistics.
According to the Standish Group (over 352 companies reporting on over 8000 projects):
- 31% of all software projects are canceled before completion
- 53% of all projects will cost 189% of the original estimate
- 9% of projects are delivered on time and on budget (in large companies)
- 16% of projects are delivered on time and on budget (in small companies)
- Lack of user input or participation - 12%
- Incomplete Requirements and Specifications - 12.3%
- Changing requirements and Specifications - 11.8%
To answer our question stated previously, what can a Project Manager do to reduce requirements errors?
Try the following:
- Structured requirements gathering meetings
- Walkthroughs and reviews of requirements with end users and customers
- Better organization and documentation of requirements
- Improved project progress reporting
- Improved requirements-based testing and requirements tracability
If you will implement the above suggestions you can reduce requirements errors by 20% or more. Any reduction in requirements errors will help to significantly reduce project cost and schedule overruns.
Wednesday, July 28, 2004
The Project Management Office
Many companies are implementing a Project Management Office (PMO). If you or your company are thinking about starting a PMO there are a few critical things you must consider.
First, there is no right or wrong model for a PMO. The issue is which PMO type is right for your organization and have you done the proper planning up front before implementing a PMO.
Before you decide on the type of PMO that is right for your company consider the following:
Do you have a Mission Statement for your PMO?
Do you have a Vision Statement (can be covered in the Mission Statement)?
Other things to consider are what Products, Services, Roles and Responsibilities will be offered by the PMO.
Once all of the above items have been finalized you are ready to build a Workplan that outlines the activities to make the PMO a reality.
First, there is no right or wrong model for a PMO. The issue is which PMO type is right for your organization and have you done the proper planning up front before implementing a PMO.
Before you decide on the type of PMO that is right for your company consider the following:
Do you have a Mission Statement for your PMO?
Do you have a Vision Statement (can be covered in the Mission Statement)?
What are the PMO's Principles (what statements will guide how the PMO will achieve its Mission)?
Who are your Customers?
Who are the Stakeholders (those people or groups that will be impacted)?
What are the Goals of the PMO (what does the PMO hope to achieve)?
What are the Objectives of the PMO (must be S.M.A.R.T)?
Note: S.M.A.R.T Objectives are (S)pecific, (M)easurable, (A)ttainable, (R)ealistic, (T)imeboundOther things to consider are what Products, Services, Roles and Responsibilities will be offered by the PMO.
Once all of the above items have been finalized you are ready to build a Workplan that outlines the activities to make the PMO a reality.
Wednesday, July 21, 2004
What is a Work Breakdown Structure?
A Work Breakdown Structure (WBS) is a deliverable-oriented grouping of project elements that organizes and defines the total scope of the project work: work not in the WBS is outside the scope of the project.
The WBS is often used to develop or confirm a common understanding of project scope. Each descending level represents and increasingly detailed description of the project elements. What does the WBS look like? Work Breakdown Structures s are communicated and organized in many ways.
The two most common ways to communicate a WBS is either a hierarchy diagram or a table of contents (TOC) layout. In some cases both formats are used to gain understanding and define the work to be performed. Typically, complex projects with a large number of internal and external stakeholders respond better to a hierarchy diagram.
However, to understand and accomplish the specific work tasks, the project team responds better to the TOC layout.
To view more information about a WBS and see an example of a WBS click here
Common approaches to Developing the WBS
The two most common approaches to developing the WBS are the top down approach and the bottom up approach. Some find a combination of both beneficial.
Top-Down Approach
The top down approach uses a predefined product development lifecycle, or a WBS template, or a WBS from a previous similar project as structured models to define the WBS from general to specific. This approach involves using a model and reviewing the major project deliverables which have been subdivided into smaller, more manageable components until the deliverables are defined in sufficient detail to support future project phases (planning, executing, controlling, and closing).
Bottom-up Approach
The bottom up approach uses a planning group to brainstorm the work elements that are needed to deliver the major deliverables of the project. A planner then groups the output from the brainstorming sessions into phases, activities and tasks. The bottom up approach involves using a small group of people (5-6) who have some subject matter expertise to plan the project.
The technique uses the brainstorming method to identify the work needing to be performed to deliver a specific thing. When the project is large or complex, the brainstorming activity is focused on a major deliverable or end product instead of the broader scope of the project. The results of the brainstorming session, generally are the pieces of work or tasks that the group knows needs to be done. It is similar to creating a “to-do list”. One of the planners then takes this information and groups the related work. These groups may then be grouped again to build up to the highest level of definitions. The information is reviewed with the original group and they modify, fix, and add any missing pieces.
Monday, July 12, 2004
Project Estimation
As stated so eloquently by Bob Lewis in his book "IS Survival Guide", There is no way for you to successfully estimate projects. Take that as a given. It can't be done, and for a very simple reason: Every one of your projects is one-of-a-kind. Mr. Lewis makes a very good point, however in my experience, I have yet to have met a manager that will let me get away with saying "I can't estimate this project".
SO WHAT IS A PROJECT MANAGER TO DO?
I like to call the solution to this problem rolling-wave estimating. By that I mean when the project is in the initiation phase and you have very little information your estimate should reflect that fact. This means very early in the project your estimate(s) could be off by as much as +200/-75% (or more). As you progress through the project planning phase you will breakdown the project into smaller, more manageable pieces of work (decomposition). This process helps to narrow the range of your estimates.
Do not be fooled into thinking that because you have broken down your project into phases and/or small manageable pieces of work that you can just add up the estimates and have a total overall project estimate. Many times, especially on IT projects, there are integration issues that are difficult to estimate and are usually ignored in the planning phase. Do not forget to add time for these critical integration activities. Also, while padding of estimates is a no-no, don't forget to account for Risk in your project estimates. PMI advocates for contingency and management reserves to account for risk events, but I have not worked in an environment where these exist so I have to plan for Risk in my estimates.
Be smart when estimating and realize that in the IT world estimates are always wrong and tasks are always underestimated.
SO WHAT IS A PROJECT MANAGER TO DO?
I like to call the solution to this problem rolling-wave estimating. By that I mean when the project is in the initiation phase and you have very little information your estimate should reflect that fact. This means very early in the project your estimate(s) could be off by as much as +200/-75% (or more). As you progress through the project planning phase you will breakdown the project into smaller, more manageable pieces of work (decomposition). This process helps to narrow the range of your estimates.
Do not be fooled into thinking that because you have broken down your project into phases and/or small manageable pieces of work that you can just add up the estimates and have a total overall project estimate. Many times, especially on IT projects, there are integration issues that are difficult to estimate and are usually ignored in the planning phase. Do not forget to add time for these critical integration activities. Also, while padding of estimates is a no-no, don't forget to account for Risk in your project estimates. PMI advocates for contingency and management reserves to account for risk events, but I have not worked in an environment where these exist so I have to plan for Risk in my estimates.
Be smart when estimating and realize that in the IT world estimates are always wrong and tasks are always underestimated.
Managing a Project in Steps
Everyone should know that for an initiative to be considered a project it must have an actual start and end date. Additionally, the project must needs a scope statement, budget, and resources.
The work in a project is considered to be unique. There may be similarities to previous projects, but no two projects are exactly the same because you will always be dealing with different circumstances and resources.
There are many different ways to manage projects and organize the work. We want to manage projects in an organized fashion using a methodology that has either been tested by others, or created for our own environment.
Step I use to manage a project are:
1. Define the Work (Concept Documents, Business Case, Charter)
2. Create the Plan (WBS, MS Work, Project, Excel)
3. Manage to the Plan (Earned Value)
4. Manage Issues
5. Manage the Scope (from the Scope Statement)
6. Manage Communications (Status Reports, Meetings)
7. Manage Risks (Risk Management Plan)
8. Manage Documentation (Document Management, Intranet/Internet)
9. Manage Quality (Quality Plan)
10. Manage Metrics (Status Reports, Earned Value)
It is important to remember as the complexity of your projects increases you will need to delve deeper and deeper into the Ten steps listed above. An excellent resource that explains how to use the above process steps is http://www.tenstep.com.
The work in a project is considered to be unique. There may be similarities to previous projects, but no two projects are exactly the same because you will always be dealing with different circumstances and resources.
There are many different ways to manage projects and organize the work. We want to manage projects in an organized fashion using a methodology that has either been tested by others, or created for our own environment.
Step I use to manage a project are:
1. Define the Work (Concept Documents, Business Case, Charter)
2. Create the Plan (WBS, MS Work, Project, Excel)
3. Manage to the Plan (Earned Value)
4. Manage Issues
5. Manage the Scope (from the Scope Statement)
6. Manage Communications (Status Reports, Meetings)
7. Manage Risks (Risk Management Plan)
8. Manage Documentation (Document Management, Intranet/Internet)
9. Manage Quality (Quality Plan)
10. Manage Metrics (Status Reports, Earned Value)
It is important to remember as the complexity of your projects increases you will need to delve deeper and deeper into the Ten steps listed above. An excellent resource that explains how to use the above process steps is http://www.tenstep.com.