This article provides a view of what has been included – and not included – in Capability Maturity Model®Integration Version 1.2 (CMMI®V1.2) for CMMI users who are familiar with the products. CMMI V1.2 products, including CMMI for Development, V1.2 (the model),
Standard CMMI Appraisal Method for Process Improvement (SCAMPISM), V1.2 (the appraisal method), and Introduction to CMMI, V1.2 (the training), was released on August 25, 2006. I describe the major elements of change for each of these CMMI products.
Draft V1.2 products were approved, piloted, and revised to ensure that the proposed changes actually improved the quality of the model, method, and training materials – and did no harm to existing improvement efforts and investments already made by those who used CMMI V1.1. I also seek to add some idea of why many of these changes were made.
http://www.stsc.hill.af.mil/crosstalk/2007/02/0702Phillips.html
Jan 10, 2008
Connecting Software Industry Standards and Best Practices: Lean Six Sigma and CMMI
Integration of Six Sigma and the Capability Maturity Model Integration (CMMI) is becoming fairly widespread, yet confusion remains about their relationship.
Part One of this article includes several case studies that answer some of the more common questions,
Part Two describes the relationship of Lean Six Sigma and Six Sigma's approach to improvement of existing products and processes (Define, Measure, Analyze, Improve, Control [DMAIC]),
and Part Three examines the relationship between Design for Lean Six Sigma (used to develop new products and processes or major enhancements) and the CMMI Engineering Process Areas.
http://www.stsc.hill.af.mil/crosstalk/2007/02/0702GackWilliams.html
Part One of this article includes several case studies that answer some of the more common questions,
Part Two describes the relationship of Lean Six Sigma and Six Sigma's approach to improvement of existing products and processes (Define, Measure, Analyze, Improve, Control [DMAIC]),
and Part Three examines the relationship between Design for Lean Six Sigma (used to develop new products and processes or major enhancements) and the CMMI Engineering Process Areas.
http://www.stsc.hill.af.mil/crosstalk/2007/02/0702GackWilliams.html
Process Improvement – Is it a Lottery?
This article provides an overview of the approach utilized to implement process improvement across its global organization without losing focus of its business drivers.
It provides a practical overview of how over a four year period an organization moved from CMM® Level 1 to Level 3 and is currently transitioning to CMMI® Level 4.
It will provide a candid insight including lessons learned and approaches adopted to achieve success.
It will also provide examples of significant and measurable business benefits that can be accrued from adopting a documented and repeatable process improvement framework.
http://www.methodsandtools.com/archive/archive.php?id=52
It provides a practical overview of how over a four year period an organization moved from CMM® Level 1 to Level 3 and is currently transitioning to CMMI® Level 4.
It will provide a candid insight including lessons learned and approaches adopted to achieve success.
It will also provide examples of significant and measurable business benefits that can be accrued from adopting a documented and repeatable process improvement framework.
http://www.methodsandtools.com/archive/archive.php?id=52
Finding CM in CMMI
Configuration management (CM) acts as a central nervous system in system development, and is a prominent key process area and generic practice in Capability Maturity Model® Integration (CMMI®) and other maturity models. As such, implementing and improving CM in the company may seem like an overwhelming task.
This article takes you through the requirements in CMMI step by step and offers practical and ready-to-use advice on how to get started and how to get better in this interesting and rewarding area.
http://www.stsc.hill.af.mil/crosstalk/2005/07/0507Hass.html
This article takes you through the requirements in CMMI step by step and offers practical and ready-to-use advice on how to get started and how to get better in this interesting and rewarding area.
http://www.stsc.hill.af.mil/crosstalk/2005/07/0507Hass.html
Relation Between CMMi and Six SIgma
Successfully implementing CMMI and Six Sigma together requires an understanding of the relationships between the two.
This report contains a brief summary of each initiative and then outlines the connections between frameworks commonly used in Six Sigma and the CMMI process areas. Coupling this knowledge with a conscious strategy enables an organization to create tactical plans and specific mappings to support implementation.
Example strategies and tactics that organizations have used to integrate these initiatives are also provided.
http://www.sei.cmu.edu/pub/documents/05.reports/pdf/05tn005.pdf
This report contains a brief summary of each initiative and then outlines the connections between frameworks commonly used in Six Sigma and the CMMI process areas. Coupling this knowledge with a conscious strategy enables an organization to create tactical plans and specific mappings to support implementation.
Example strategies and tactics that organizations have used to integrate these initiatives are also provided.
http://www.sei.cmu.edu/pub/documents/05.reports/pdf/05tn005.pdf
Basic Project Management Outline
A successful Project Manager must simultaneously manage the four basic elements of a project: resources, time, money, and most importantly, scope. All these elements are interrelated. Each must be managed effectively.
All must be managed together if the project, and the project manager, is to be a success.
Resources : People, equipment, material
Time : Task durations, dependencies, critical path
Money: Costs, contingencies, profit
Scope: Project size, goals, requirements
Most literature on project management speaks of the need to manage and balance three elements: people, time, and money. However, the fourth element is the most important and it is the first and last task for a successful project manager.
First and foremost you have to manage the project scope.
The project scope is the definition of what the project is supposed to accomplish and the budget (of time and money) that has been created to achieve these objectives. It is absolutely imperative that any change to the scope of the project have a matching change in budget, either time or resources. If the project scope is to build a building to house three widgets with a budget of $100,000 the project manager is expected to do that. However, if the scope is changed to a building for four widgets, the project manager must obtain an appropriate change in budgeted resources. If the budget is not adjusted, the smart project manager will avoid the change in scope.
Usually, scope changes occur in the form of "scope creep". Scope creep is the piling up of small changes that by themselves are manageable, but in agregate are significant. For example, the project callls for a building to be 80,000 square feet in size. The client wants to add a ten foot long, 4 foot wide awning over one bay door. That's a pretty minor change. Later the client wants to extend the awing 8 feet to cover the adjacent bay. Another minor change. Then it's a change to block the upwind side to the covered area to keep out the wind. Later, it's a request to block the other end to make the addition more symetrical. Eventually, the client asks for a ceiling under the awning, lights in the ceiling, electrical outlets, a water faucet for the workers, some sound-proofing, and a security camera. By now, the minor change has become a major addition.
Make sure any requested change, no matter how small, is accompanied by approval for a change in budget or schedule or both.
You can not effectively manage the resources, time and money in a project unless you actively manage the project scope.
When you have the project scope clearly identified and associated to the timeline and budget, you can begin to manage the project resources. These include the people, equipment, and material needed to complete the project.
Part 2: Managing Resources - People, Equipment, and Material
A successful Project Manager must effectively manage the resources assigned to the project. This includes the labor hours of the designers, the builders, the testers and the inspectors on the project team. It also include managing any labor subcontracts. However, managing project resources frequently involves more than people management. The project manager must also manage the equipment used for the project and the material needed by the people and equipment assigned to the project.
People: Project employees, vendor staff, subcontract labor
Equipment: Cranes, trucks, backhoes, other heavy equipment or Development, test, and staging servers, CD burners or Recording studio, tape decks, mixers, microphones and speakers
Material: Concrete, pipe, rebar, insulation or CD blanks, computers, jewel cases, instruction manuals
Managing the people resources means having the right people, with the right skills and the proper tools, in the right quantity at the right time.
It also means ensuring that they know what needs to be done, when, and how. And it means motivating them to take ownership in the project too.
Managing direct employees normally means managing the senior person in each group of employees assigned to your project. Remember that these employees also have a line manager to whom they report and from whom the usually take technical direction. In a matrix management situation, like a project team, your job is to provide project direction to them.
Managing labor subcontracts usually means managing the team lead for the subcontracted workers, who in turn manages the workers.
The equipment you have to manage as part of your project depends on the nature of the project. A project to construct a frozen food warehouse would need earth moving equipment, cranes, and cement trucks. For a project to release a new version of a computer game, the equipment would include computers, test equipment, and duplication and packaging machinery. The project management key for equipment is much like for people resources. You have to make sure you have the right equipment in the right place at the right time and that it has the supplies it needs to operate properly.
Most projects involve the purchase of material. For a frozen food warehouse, this would be freezers, the building HVAC machinery and the material handling equipment. For a project to release a music CD by a hot new artist, it would include the CD blanks, artwork for the jewel case, and press releases to be sent to deejays. The project management issue with supplies is to make sure the right supplies arrive at the right time (we'll talk about the right price later).
All your skill in managing resources won't help, however, unless you can stick to the project schedule. Time management is critical in successful project management.
Part 3: Managing Time and Schedule
Time management is a critically important skill for any successful project manager. I have observed that Project Managers who succeed in meeting their project schedule have a good chance of staying within their project budget. The most common cause of blown project budgets is lack of schedule management. Fortunately there is a lot of software on the market today to help you manage your project schedule or timeline.
Tasks: Duration, resources, dependencies
Schedule: Tasks, predecessors, successors
Critical Path: Changeable, often multiple, float
Any project can be broken down into a number of tasks that have to be performed. To prepare the project schedule, the project manager has to figure out what the tasks are, how long they will take, what resources they require, and in what order they should be done.
Each of these elements has a direct bearing on the schedule.
If you omit a task, the project won't be completed. If you underestimate the length of time or the amount of resources required for the task, you may miss your schedule. The schedule can also be blown if you make a mistake in the sequencing of the tasks.
Build the project schedule by listing, in order, all the tasks that need to be completed. Assign a duration to each task. Allocate the required resources. Determine predecessors (what tasks must be completed before) and successors (tasks that can't start until after) each task. It's pretty simple and straightforward. For instance, think of a project called "Getting Dressed In The Morning". The task "put on shirt" may have a longer duration if it is a buttoned dress shirt than if it's a pullover. It doesn't matter which order you complete the tasks "put on right shoe" and "put on left shoe", but it is important to complete the "put on pants" task before starting the "put on shoes" task.
The difficulty in managing a project schedule is that there are seldom enough resources and enough time to complete the tasks sequentially. Therefore, tasks have to be overlapped so several happen at the same time. Project management software (see sidebar) greatly simplifies the task of creating and managing the project schedule by handling the iterations in the schedule logic for you.
When all tasks have been listed, resourced, and sequenced, you will see that some tasks have a little flexibility in their required start and finish date. This is called float. Other tasks have no flexibility, zero float. A line through all the tasks with zero float is called the critical path. All tasks on this path, and there can be multiple, parallel paths, must be completed on time if the project is to be completed on time. The Project Manager's key time management task is to manage the critical path.
Be aware, that items can be added to or removed from the critical path as circumstances change during the execution of the project. Installation of security cameras may not be on the critical path, but if the shipment is delayed, it may become part of the critical path. Conversely, pouring the concrete foundation may be on the critical path, but if the project manager obtains an addition crew and the pour is completed early it could come off the critical path (or reduce the length of the critical path).
Regardless of how well you manage the schedule and the resources, there is one more critical element - managing the budget.
Part 4: Managing Costs, Money, and Profits
Often a Project Manager is evaluated on his or her ability to complete a project within budget. If you have effectively managed the project resources and project schedule, this should not be a problem. It is, however, a task that requires the project manager's careful attention. You can only manage effectively a limited number of cost items, so focus on the critical ones (see the 80-20 Rule in the sidebar).
Costs: Estimated, actual, variability
Contingencies: Weather, suppliers, design allowance
Profit: Cost, contingencies, remainder
Each project task will have a cost, whether it is the cost of the labor hours of a computer programmer or the purchase price of a cubic yard of concrete. In preparing the project budget, each of these costs is estimated and then totaled.
Some of these estimates will be more accurate than others. A company knows what it will charge each of its projects for different classifications of labor. Commodities like concrete are priced in a very competitive market so prices are fairly predictable. Other estimates are less accurate. For instance, the cost of a conveyor system with higher performance specifications that normal can be estimated to be more expensive, but it is hard to determine whether it will be 10% more or 15% more. For an expensive item, that can be a significant amount.
When the estimated cost of an item is uncertain, the project budget often includes a design allowance. This is money that is set aside in the budget "just in case" the actual cost of the item is wildly different than the estimate.
Unusual weather or problems with suppliers are always a possibility on large projects. Companies usually include a contingency amount in the project budget to cover these kinds of things.
So a project budget is composed of the estimated cost, plus the contingency and design allowance, plus any profit. The project manager's job is to keep the actual cost at or below the estimated cost, to use as little of the design allowance and contingency as possible, and to maximize the profit the company earns on the project.
To maximize your chances of meeting your project budget, meet your project schedule. The most common cause of blown budgets is blown schedules. Meeting the project schedule won't guarantee you will meet the project budget, but it significantly increases your chances. And above all, manage the project scope. Don't allow the project scope to "creep" upward without getting budget and/or schedule adjustments to match.
Successful project management is an art and a science that takes practice. The ideas presented above can give you a basic understanding of project management, but consider it only a beginning. If your job or career path includes project management, and you want to improve your skills, talk to successful project managers, read, and practice. Project management can be a very rewarding career.
How To Manage A Project
Here's How:
Define the Scope: The first, and most important, step in any project is defining the scope of the project. What is it you are supposed to accomplish by managing this project? What is the project objective? Equally important is defining what is not included in the scope of your project. If you don't get enough definition from your boss, clarify the scope yourself and send it back upstairs for confirmation.
Determine Available Resources: What people, equipment, and money will you have available to you to achieve the project objectives? As a project manager, you usually will not have direct control of these resources, but will have to manage them through matrix management. Find out how easy or difficult that will be to do.
Check the Timeline: When does the project have to be completed? As you develop your project plan you may have some flexibility in how you use time during the project, but deadlines usually are fixed. If you decide to use overtime hours to meet the schedule, you must weigh that against the limitations of your budget.
Assemble Your Project Team: Get the people on your team together and start a dialog. They are the technical experts. That's why their functional supervisor assigned them to the project. Your job is to manage the team.
zSB(3,3)
Sponsored Links
Project Mgmt Certificate100% online courses from the University of British Columbia.www.tech.ubc.ca
Project ManagementLeading Software for project mgt. Free info, whitepapers, webcasts.www.deltek.com
Web Project ManagementManage portfolios, projects, costs, resources, time, issues, documents.www.sciforma.com
List the Big Steps: What are the major pieces of the project? If you don't know, start by asking your team. It is a good idea to list the steps in chronological order but don't obsess about it; you can always change the order later.
List the Smaller Steps: List the smaller steps in each of the larger steps. Again, it usually helps you remember all the steps if you list them in chronological order. How many levels deep you go of more and more detailed steps depends on the size and complexity of your project.
Develop a Preliminary Plan: Assemble all your steps into a plan. What happens first? What is the next step? Which steps can go on at the same time with different resources? Who is going to do each step? How long will it take? There are many excellent software packages available that can automate a lot of this detail for you. Ask others in similar positions what they use.
Create Your Baseline Plan: Get feedback on your preliminary plan from your team and from any other stakeholders. Adjust your timelines and work schedules to fit the project into the available time. Make any necessary adjustments to the preliminary plan to produce a baseline plan.
Request Project Adjustments: There is almost never enough time, money or talent assigned to a project. Your job is to do more with the limited resources than people expect. However, there are often limits placed on a project that are simply unrealistic. You need to make your case and present it to your boss and request these unrealistic limits be changed. Ask for the changes at the beginning of the project. Don't wait until it's in trouble to ask for the changes you need.
Work Your Plan, But Don't Die For ItMaking the plan is important, but the plan can be changed. You have a plan for driving to work every morning. If one intersection is blocked by an accident, you change your plan and go a different way. Do the same with your project plans. Change them as needed, but always keep the scope and resources in mind.
Monitor Your Team's ProgressYou will make little progress at the beginning of the project, but start then to monitor what everyone is doing anyway. That will make it easier to catch issues before they become problems.
Document Everything: Keep records. Every time you change from your baseline plan, write down what the change was and why it was necessary. Every time a new requirement is added to the project write down where the requirement came from and how the timeline or budget was adjusted because of it. You can't remember everything, so write them down so you'll be able to look them up at the end-of-project review and learn from them.
Keep Everyone Informed: Keep all the project stakeholders informed of progress all along. Let them know of your success as you complete each milestone, but also inform them of problems as soon as they come up. Also keep you team informed. If changes are being considered, tell the team about them as far ahead as you can. Make sure everyone on the team is aware of what everyone else is doing.
From F. John Reh,Your Guide to Management.
All must be managed together if the project, and the project manager, is to be a success.
Resources : People, equipment, material
Time : Task durations, dependencies, critical path
Money: Costs, contingencies, profit
Scope: Project size, goals, requirements
Most literature on project management speaks of the need to manage and balance three elements: people, time, and money. However, the fourth element is the most important and it is the first and last task for a successful project manager.
First and foremost you have to manage the project scope.
The project scope is the definition of what the project is supposed to accomplish and the budget (of time and money) that has been created to achieve these objectives. It is absolutely imperative that any change to the scope of the project have a matching change in budget, either time or resources. If the project scope is to build a building to house three widgets with a budget of $100,000 the project manager is expected to do that. However, if the scope is changed to a building for four widgets, the project manager must obtain an appropriate change in budgeted resources. If the budget is not adjusted, the smart project manager will avoid the change in scope.
Usually, scope changes occur in the form of "scope creep". Scope creep is the piling up of small changes that by themselves are manageable, but in agregate are significant. For example, the project callls for a building to be 80,000 square feet in size. The client wants to add a ten foot long, 4 foot wide awning over one bay door. That's a pretty minor change. Later the client wants to extend the awing 8 feet to cover the adjacent bay. Another minor change. Then it's a change to block the upwind side to the covered area to keep out the wind. Later, it's a request to block the other end to make the addition more symetrical. Eventually, the client asks for a ceiling under the awning, lights in the ceiling, electrical outlets, a water faucet for the workers, some sound-proofing, and a security camera. By now, the minor change has become a major addition.
Make sure any requested change, no matter how small, is accompanied by approval for a change in budget or schedule or both.
You can not effectively manage the resources, time and money in a project unless you actively manage the project scope.
When you have the project scope clearly identified and associated to the timeline and budget, you can begin to manage the project resources. These include the people, equipment, and material needed to complete the project.
Part 2: Managing Resources - People, Equipment, and Material
A successful Project Manager must effectively manage the resources assigned to the project. This includes the labor hours of the designers, the builders, the testers and the inspectors on the project team. It also include managing any labor subcontracts. However, managing project resources frequently involves more than people management. The project manager must also manage the equipment used for the project and the material needed by the people and equipment assigned to the project.
People: Project employees, vendor staff, subcontract labor
Equipment: Cranes, trucks, backhoes, other heavy equipment or Development, test, and staging servers, CD burners or Recording studio, tape decks, mixers, microphones and speakers
Material: Concrete, pipe, rebar, insulation or CD blanks, computers, jewel cases, instruction manuals
Managing the people resources means having the right people, with the right skills and the proper tools, in the right quantity at the right time.
It also means ensuring that they know what needs to be done, when, and how. And it means motivating them to take ownership in the project too.
Managing direct employees normally means managing the senior person in each group of employees assigned to your project. Remember that these employees also have a line manager to whom they report and from whom the usually take technical direction. In a matrix management situation, like a project team, your job is to provide project direction to them.
Managing labor subcontracts usually means managing the team lead for the subcontracted workers, who in turn manages the workers.
The equipment you have to manage as part of your project depends on the nature of the project. A project to construct a frozen food warehouse would need earth moving equipment, cranes, and cement trucks. For a project to release a new version of a computer game, the equipment would include computers, test equipment, and duplication and packaging machinery. The project management key for equipment is much like for people resources. You have to make sure you have the right equipment in the right place at the right time and that it has the supplies it needs to operate properly.
Most projects involve the purchase of material. For a frozen food warehouse, this would be freezers, the building HVAC machinery and the material handling equipment. For a project to release a music CD by a hot new artist, it would include the CD blanks, artwork for the jewel case, and press releases to be sent to deejays. The project management issue with supplies is to make sure the right supplies arrive at the right time (we'll talk about the right price later).
All your skill in managing resources won't help, however, unless you can stick to the project schedule. Time management is critical in successful project management.
Part 3: Managing Time and Schedule
Time management is a critically important skill for any successful project manager. I have observed that Project Managers who succeed in meeting their project schedule have a good chance of staying within their project budget. The most common cause of blown project budgets is lack of schedule management. Fortunately there is a lot of software on the market today to help you manage your project schedule or timeline.
Tasks: Duration, resources, dependencies
Schedule: Tasks, predecessors, successors
Critical Path: Changeable, often multiple, float
Any project can be broken down into a number of tasks that have to be performed. To prepare the project schedule, the project manager has to figure out what the tasks are, how long they will take, what resources they require, and in what order they should be done.
Each of these elements has a direct bearing on the schedule.
If you omit a task, the project won't be completed. If you underestimate the length of time or the amount of resources required for the task, you may miss your schedule. The schedule can also be blown if you make a mistake in the sequencing of the tasks.
Build the project schedule by listing, in order, all the tasks that need to be completed. Assign a duration to each task. Allocate the required resources. Determine predecessors (what tasks must be completed before) and successors (tasks that can't start until after) each task. It's pretty simple and straightforward. For instance, think of a project called "Getting Dressed In The Morning". The task "put on shirt" may have a longer duration if it is a buttoned dress shirt than if it's a pullover. It doesn't matter which order you complete the tasks "put on right shoe" and "put on left shoe", but it is important to complete the "put on pants" task before starting the "put on shoes" task.
The difficulty in managing a project schedule is that there are seldom enough resources and enough time to complete the tasks sequentially. Therefore, tasks have to be overlapped so several happen at the same time. Project management software (see sidebar) greatly simplifies the task of creating and managing the project schedule by handling the iterations in the schedule logic for you.
When all tasks have been listed, resourced, and sequenced, you will see that some tasks have a little flexibility in their required start and finish date. This is called float. Other tasks have no flexibility, zero float. A line through all the tasks with zero float is called the critical path. All tasks on this path, and there can be multiple, parallel paths, must be completed on time if the project is to be completed on time. The Project Manager's key time management task is to manage the critical path.
Be aware, that items can be added to or removed from the critical path as circumstances change during the execution of the project. Installation of security cameras may not be on the critical path, but if the shipment is delayed, it may become part of the critical path. Conversely, pouring the concrete foundation may be on the critical path, but if the project manager obtains an addition crew and the pour is completed early it could come off the critical path (or reduce the length of the critical path).
Regardless of how well you manage the schedule and the resources, there is one more critical element - managing the budget.
Part 4: Managing Costs, Money, and Profits
Often a Project Manager is evaluated on his or her ability to complete a project within budget. If you have effectively managed the project resources and project schedule, this should not be a problem. It is, however, a task that requires the project manager's careful attention. You can only manage effectively a limited number of cost items, so focus on the critical ones (see the 80-20 Rule in the sidebar).
Costs: Estimated, actual, variability
Contingencies: Weather, suppliers, design allowance
Profit: Cost, contingencies, remainder
Each project task will have a cost, whether it is the cost of the labor hours of a computer programmer or the purchase price of a cubic yard of concrete. In preparing the project budget, each of these costs is estimated and then totaled.
Some of these estimates will be more accurate than others. A company knows what it will charge each of its projects for different classifications of labor. Commodities like concrete are priced in a very competitive market so prices are fairly predictable. Other estimates are less accurate. For instance, the cost of a conveyor system with higher performance specifications that normal can be estimated to be more expensive, but it is hard to determine whether it will be 10% more or 15% more. For an expensive item, that can be a significant amount.
When the estimated cost of an item is uncertain, the project budget often includes a design allowance. This is money that is set aside in the budget "just in case" the actual cost of the item is wildly different than the estimate.
Unusual weather or problems with suppliers are always a possibility on large projects. Companies usually include a contingency amount in the project budget to cover these kinds of things.
So a project budget is composed of the estimated cost, plus the contingency and design allowance, plus any profit. The project manager's job is to keep the actual cost at or below the estimated cost, to use as little of the design allowance and contingency as possible, and to maximize the profit the company earns on the project.
To maximize your chances of meeting your project budget, meet your project schedule. The most common cause of blown budgets is blown schedules. Meeting the project schedule won't guarantee you will meet the project budget, but it significantly increases your chances. And above all, manage the project scope. Don't allow the project scope to "creep" upward without getting budget and/or schedule adjustments to match.
Successful project management is an art and a science that takes practice. The ideas presented above can give you a basic understanding of project management, but consider it only a beginning. If your job or career path includes project management, and you want to improve your skills, talk to successful project managers, read, and practice. Project management can be a very rewarding career.
How To Manage A Project
Here's How:
Define the Scope: The first, and most important, step in any project is defining the scope of the project. What is it you are supposed to accomplish by managing this project? What is the project objective? Equally important is defining what is not included in the scope of your project. If you don't get enough definition from your boss, clarify the scope yourself and send it back upstairs for confirmation.
Determine Available Resources: What people, equipment, and money will you have available to you to achieve the project objectives? As a project manager, you usually will not have direct control of these resources, but will have to manage them through matrix management. Find out how easy or difficult that will be to do.
Check the Timeline: When does the project have to be completed? As you develop your project plan you may have some flexibility in how you use time during the project, but deadlines usually are fixed. If you decide to use overtime hours to meet the schedule, you must weigh that against the limitations of your budget.
Assemble Your Project Team: Get the people on your team together and start a dialog. They are the technical experts. That's why their functional supervisor assigned them to the project. Your job is to manage the team.
zSB(3,3)
Sponsored Links
Project Mgmt Certificate100% online courses from the University of British Columbia.www.tech.ubc.ca
Project ManagementLeading Software for project mgt. Free info, whitepapers, webcasts.www.deltek.com
Web Project ManagementManage portfolios, projects, costs, resources, time, issues, documents.www.sciforma.com
List the Big Steps: What are the major pieces of the project? If you don't know, start by asking your team. It is a good idea to list the steps in chronological order but don't obsess about it; you can always change the order later.
List the Smaller Steps: List the smaller steps in each of the larger steps. Again, it usually helps you remember all the steps if you list them in chronological order. How many levels deep you go of more and more detailed steps depends on the size and complexity of your project.
Develop a Preliminary Plan: Assemble all your steps into a plan. What happens first? What is the next step? Which steps can go on at the same time with different resources? Who is going to do each step? How long will it take? There are many excellent software packages available that can automate a lot of this detail for you. Ask others in similar positions what they use.
Create Your Baseline Plan: Get feedback on your preliminary plan from your team and from any other stakeholders. Adjust your timelines and work schedules to fit the project into the available time. Make any necessary adjustments to the preliminary plan to produce a baseline plan.
Request Project Adjustments: There is almost never enough time, money or talent assigned to a project. Your job is to do more with the limited resources than people expect. However, there are often limits placed on a project that are simply unrealistic. You need to make your case and present it to your boss and request these unrealistic limits be changed. Ask for the changes at the beginning of the project. Don't wait until it's in trouble to ask for the changes you need.
Work Your Plan, But Don't Die For ItMaking the plan is important, but the plan can be changed. You have a plan for driving to work every morning. If one intersection is blocked by an accident, you change your plan and go a different way. Do the same with your project plans. Change them as needed, but always keep the scope and resources in mind.
Monitor Your Team's ProgressYou will make little progress at the beginning of the project, but start then to monitor what everyone is doing anyway. That will make it easier to catch issues before they become problems.
Document Everything: Keep records. Every time you change from your baseline plan, write down what the change was and why it was necessary. Every time a new requirement is added to the project write down where the requirement came from and how the timeline or budget was adjusted because of it. You can't remember everything, so write them down so you'll be able to look them up at the end-of-project review and learn from them.
Keep Everyone Informed: Keep all the project stakeholders informed of progress all along. Let them know of your success as you complete each milestone, but also inform them of problems as soon as they come up. Also keep you team informed. If changes are being considered, tell the team about them as far ahead as you can. Make sure everyone on the team is aware of what everyone else is doing.
From F. John Reh,Your Guide to Management.
Jan 9, 2008
Quality-Process-Software-CMMI-ISO-SixSigma
Differences between Continuous and Staged Representations in CMMI
http://www.sei.cmu.edu/cmmi/presentations/sepg05.presentations/cepeda-cmmi.pdf
CMMI 1.2 for Development online - browser version
http://www.wibas.de/presentation/site/cmmi_1.2_browser.html.en
This is the link to see online version of CMMI 1.2 for development
http://chrguibert.free.fr/cmmi12/text/index.php
What is not CMMI Level 4 and 5
http://www.sei.cmu.edu/appraisal-program/presentations/hi-matmis.pdf
Causal Analysis and Resolution: A Business Driver at All Levels http://www.dtic.mil/ndia/2002cmmi/norausky3a1.pdf
Quality Glossary
http://www.isixsigma.com/dictionary/glossary.asp
Quality Methodologies
http://www.isixsigma.com/me/
Statistics in Quality
http://www.isixsigma.com/st/
Quality Tools
http://www.isixsigma.com/tt/-
5Whys http://www.protoolkits.com/Analysisandrequirements/Analysistechniques/fivewhys.html-
Fishbone Diagrams
http://www.protoolkits.com/Analysisandrequirements/Analysistechniques/fishbonediagrams.html
Manage Changes
http://www.protoolkits.com/Analysisandrequirements/managechangerequests.html-
Process Maps
http://www.protoolkits.com/Analysisandrequirements/Analysistechniques/processmaps.html
One who wants to know about CMMI and related stuff, become a member in https://seir.sei.cmu.edu/seir
[Site will ask you about the work you do and why you want to become a member.]
Some Project Management Literature Templates and Checklists can be found athttp://www.brookes.ac.uk/services/hr/project/templates/index.html
Project Management Reference Site
http://www.managementhelp.org/plan_dec/project/project.htmhttp://www.method123.com/free-project-management-book.php
Some Suggested Readings
www.processimpact.com/PMBP/Module_8/data/downloads/metrics_traps.pdf http://www.processimpact.com/pubs.shtml#requirements http://www.processimpact.com/articles/metrics_primer.html
Agile Methodologies and Related Links
http://www.extremeprogramming.org/ -eXtreameProgramming
http://www.controlchaos.com/ - Scrum
http://www.agilemetrics.com/ - Agilemetrics site
http://www.blueink.biz/RapidApplicationDevelopment.aspx RAD
http://www.controlchaos.com/ - Scrum
http://www.agilemetrics.com/ - Agilemetrics site
http://www.blueink.biz/RapidApplicationDevelopment.aspx RAD
Introduction to SoftwareEstimation
Estimation is done in terms of* Size*Effort* Schedule* Cost
Size estimate: This is thefirst estimation task. A measurement that tells the user what the system shalldo. Size estimate is usually done by Function Points Analysis, Feature points,Use Case points or Lines of Code (LOC).
Effortestimate: The estimate for the manpower that is requiredfor a project. This is a most important factor determines many crucialdecisions.Measured in terms of : person-hours, person-days,person-months, etc.
The popular effort estimation methods are:
size=2>* COCOMO 81
* COCOMO II
* Putnam’s Software Equation
*Felix-Watson
* Bailey-Basili
Example: If requirement is to build a web based system withLogin mechanism. The Size Estimate in terms of LOC may come to 150 Lines, andEffort estimate would be 8 person hours. Hence Effort estimate isdependent on size estimate.
Schedule estimate: Thisis the duration between the start of the project and the end of the projectOften effort estimate are revised to meet the customer imposed scheduleRepresented in terms of : Calendar-months, calendar-days, weeks, etc.
Cost estimate: A major driver of cost estimation is the manpower cost (based on the estimatedeffort).
Other costs include : travel, communication, facilities, projectspecific training , hardware and software costs for the project team, etc.
High Quality & Productivity (Q&P) reduce the cost and minimize theschedule of a project. Q&P are the twin aims of a project. Hgh Q&P canbe maintained by employing good processes.
Size estimate: This is thefirst estimation task. A measurement that tells the user what the system shalldo. Size estimate is usually done by Function Points Analysis, Feature points,Use Case points or Lines of Code (LOC).
Effortestimate: The estimate for the manpower that is requiredfor a project. This is a most important factor determines many crucialdecisions.Measured in terms of : person-hours, person-days,person-months, etc.
The popular effort estimation methods are:
size=2>* COCOMO 81
* COCOMO II
* Putnam’s Software Equation
*Felix-Watson
* Bailey-Basili
Example: If requirement is to build a web based system withLogin mechanism. The Size Estimate in terms of LOC may come to 150 Lines, andEffort estimate would be 8 person hours. Hence Effort estimate isdependent on size estimate.
Schedule estimate: Thisis the duration between the start of the project and the end of the projectOften effort estimate are revised to meet the customer imposed scheduleRepresented in terms of : Calendar-months, calendar-days, weeks, etc.
Cost estimate: A major driver of cost estimation is the manpower cost (based on the estimatedeffort).
Other costs include : travel, communication, facilities, projectspecific training , hardware and software costs for the project team, etc.
High Quality & Productivity (Q&P) reduce the cost and minimize theschedule of a project. Q&P are the twin aims of a project. Hgh Q&P canbe maintained by employing good processes.
Jan 8, 2008
Statistical process control (SPC)
Statistical process control (SPC) is a method for achieving quality control in manufacturing processes. It is a set of methods using statistical tools such as mean, variance and others, to detect whether the process observed is under control.
History
Statistical process control was pioneered by Walter A. Shewhart and taken up by W. Edwards Deming with significant effect by the Americans during the World War II to improve aircraft production. Deming was also instrumental in introducing SPC techniques into Japanese industry after that war.
General
Classical Quality Control was achieved by observing important properties of the finished product and accept/reject the finished product. As opposed to this statistical process control uses statistical tools to observe the performance of the production line to predict significant deviations that may result in reject products.
The underlying assumption in the SPC method is that any production process will produce products whose properties vary slightly from their designed values, even when the production line is running normally, and these variances can be analyzed statistically to control the process.
For example, a breakfast cereal packaging line may be designed to fill each cereal box with 500 grams of product, but some boxes will have slightly more than 500 grams, and some will have slightly less, producing a distribution of net weights. If the production process itself changes (for example, the machines doing the manufacture begin to wear) this distribution can shift or spread out. For example, as its cams and pulleys wear out, the cereal filling machine may start putting more cereal into each box than it was designed to. If this change is allowed to continue unchecked, product may be produced that fall outside the tolerances of the manufacturer or consumer, causing product to be rejected.
By using statistical tools, the operator of the production line can discover that a significant change has been made to the production line, by wear and tear or other means, and correct the problem - or even stop production - before producing product outside specifications. An example of such a statistical tool would be the Shewhart control chart, and the operator in the aforementioned example plotting the net weight in the Shewhart chart.
QA , QC & Quality tools
Quality Assurance , Quality Control & Quality tools
Just In Time (JIT) is an inventory strategy implemented to improve the return on investment of a business by reducing in-process inventory and its associated costs. The process is driven by a series of signals, or Kanban that tell production processes to make the next part. Kanban are usually simple visual signals, such as the presence or absence of a part on a shelf. JIT can lead to dramatic improvements in a manufacturing organization's return on investment, quality, and efficiency when implemented correctly.
New stock is ordered when stock reaches the re-order level. This saves warehouse space and costs. However, one drawback of the JIT system is that the re-order level is determined by historical demand. If demand rises above the historical average planning duration demand, the firm could deplete inventory and cause customer service issues. To meet a 95% service rate a firm must carry about 2 standard deviations of demand in safety stock. Forecasted shifts in demand should be planned for around the Kanban until trends can be established to reset the appropriate Kanban level. In recent years manufacturers have touted a trailing 13 week average is a better predictor than most forecastors could provide.
For More info refer
http://en.wikipedia.org/wiki/Just_In_Time
Kaizen (改善, Japanese for "change for the better" or "improvement") is an approach to productivity improvement originating in applications of the work of American experts such as Frederick Winslow Taylor, Frank Bunker Gilbreth, Walter Shewhart,and of the War Department's Training Within Industry program by post-WWII Japanese manufacturers. The development of Kaizen went hand-in-hand with that of Quality control circles, but it was not limited to quality assurance.
The goals of kaizen include the elimination of waste (defined as "activities that add cost but do not add value"), just-in-time delivery, production load leveling of amount and types, standardized work, paced moving lines, right-sized equipment, and others. A closer definition of the Japanese usage of Kaizen is "to take it apart and put back together in a better way." What is taken apart is usually a process, system, product, or service.
Kaizen is a daily activity whose purpose goes beyond improvement. It is also a process that when done correctly humanizes the workplace, eliminates hard work (both mental and physical), teaches people how to do rapid experiments using the scientific method, and how to learn to see and eliminate waste in business processes.
"Kaizen" is the correct usage. "Kaizen event" or "kaizen blitz" are incorrect usage.
Kaizen is often misunderstood and applied incorrectly, resulting in bad outcomes including, for example, layoffs. This is called "kaiaku" - literally, "change for the worse." Layoffs are not the intent of kaizen. Instead, kaizen must be practiced in tandem with the "Respect for People" principle. Without "Respect for People," there can be no continuous improvement. Instead, the usual result is one-time gains that quickly fade.
Importantly, kaizen must operate with three principles in place: process and results (not results-only); systemic thinking (i.e. big picture, not solely the narrow view); and non judgmental, non-blaming (because blaming is wasteful).
Everyone participates in kaizen; people of all levels in an organization, CEO on down, as well as external stakeholders if needed. The format for kaizen can be individual, suggestion system, small group, or large group.
The only way to truly understand the intent, meaning, and power of kaizen is through direct participation - many, many times.
Lean accounting and just in time producton are related concepts.
Process Models
A decades-long goal has been to find repeatable, predictable processes or methodologies (software engineering) that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management is proving difficult.
Waterfall processes
The best-known and oldest process is the waterfall model, where developers (roughly) follow these steps in order. They state requirements, analyze them, design a solution approach, architect a software framework for that solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected. If iteration is not included in the planning, the process has no provision for correcting errors in early steps (for example, in the requirements), so the entire (expensive) engineering process may be executed to the end, resulting in unusable or unneeded software features.
In old style (CMM) processes, architecture and design preceded coding, usually by separate people in a separate process step.
Iterative processes
Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what he wants.
Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability. In essence, they say that they will provide the most bang for the buck, but won't say exactly when that bang will be.
Extreme Programming, XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.
While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.
Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer. The approach can also be very expensive, akin to... "If you don't know what kind of house you want, let me build you one and see if you like it. If you don't, we'll tear it all down and start over." A large pile of building-materials, which are now scrap, can be the final result of such a lack of up-front discipline.
Formal methods
Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behaviour by designing a system of finite state machines.
Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine).
Recent approaches try to merge the specification and code into one activity to ensure the specification and code match. While Agile methods propagate specification of all requirements in code, methods such as VFSM develop executable specifications, trying to avoid the coding activity entirely
Quality control tools
The following are the mostwidely used Quality control tools
Run Chart :Run charts are used to analyze processes according to time or order. Run charts are useful in discovering patterns that occur over time. Detailed tutorial
Pareto Chart :Pareto charts are extremely useful because they can be used to identify those factors that have the greatest cumulative effect on the system, and thus screen out the less significant factors in an analysis. Ideally, this allows the user to focus attention on a few important factors in a process.
Flow Chart :Flowcharts are pictorial representations of a process. By breaking the process down into its constituent steps, flowcharts can be useful in identifying where errors are likely to be found in the system. Detailed tutorial
Cause and Effect Diagram :Thisdiagram, also called an Ishikawa diagram (or fish bone diagram), is used to associate multiple possible causes with a single effect. Thus, given a particular effect, the diagram is constructed to identify and organize possible causes for it. Detailed tutorial
Histogram :Histograms provide a simple, graphical view of accumulated data, including its dispersionand central tendancy. In addition to the ease with which they can beconstructed, histograms provide the easiest way to evaluate the distribution ofdata. Detailed tutorial
Scatter diagrams : Scatter diagramsare graphical tools that attempt to depict the influence that one variable has on another. A common diagram of this type usually displays points representing the observed value of one variable corresponding to the value of another variable. Detailed tutorial
Control Chart :The control chart is the fundamental tool of statistical process control, as it indicates the range of variability that is built into a system (known as common cause variation). Thus, it helps determine whether or not a process is operating consistently or if a special cause has occurred to change the process mean or variance.
History
Statistical process control was pioneered by Walter A. Shewhart and taken up by W. Edwards Deming with significant effect by the Americans during the World War II to improve aircraft production. Deming was also instrumental in introducing SPC techniques into Japanese industry after that war.
General
Classical Quality Control was achieved by observing important properties of the finished product and accept/reject the finished product. As opposed to this statistical process control uses statistical tools to observe the performance of the production line to predict significant deviations that may result in reject products.
The underlying assumption in the SPC method is that any production process will produce products whose properties vary slightly from their designed values, even when the production line is running normally, and these variances can be analyzed statistically to control the process.
For example, a breakfast cereal packaging line may be designed to fill each cereal box with 500 grams of product, but some boxes will have slightly more than 500 grams, and some will have slightly less, producing a distribution of net weights. If the production process itself changes (for example, the machines doing the manufacture begin to wear) this distribution can shift or spread out. For example, as its cams and pulleys wear out, the cereal filling machine may start putting more cereal into each box than it was designed to. If this change is allowed to continue unchecked, product may be produced that fall outside the tolerances of the manufacturer or consumer, causing product to be rejected.
By using statistical tools, the operator of the production line can discover that a significant change has been made to the production line, by wear and tear or other means, and correct the problem - or even stop production - before producing product outside specifications. An example of such a statistical tool would be the Shewhart control chart, and the operator in the aforementioned example plotting the net weight in the Shewhart chart.
QA , QC & Quality tools
Quality Assurance , Quality Control & Quality tools
Just In Time (JIT) is an inventory strategy implemented to improve the return on investment of a business by reducing in-process inventory and its associated costs. The process is driven by a series of signals, or Kanban that tell production processes to make the next part. Kanban are usually simple visual signals, such as the presence or absence of a part on a shelf. JIT can lead to dramatic improvements in a manufacturing organization's return on investment, quality, and efficiency when implemented correctly.
New stock is ordered when stock reaches the re-order level. This saves warehouse space and costs. However, one drawback of the JIT system is that the re-order level is determined by historical demand. If demand rises above the historical average planning duration demand, the firm could deplete inventory and cause customer service issues. To meet a 95% service rate a firm must carry about 2 standard deviations of demand in safety stock. Forecasted shifts in demand should be planned for around the Kanban until trends can be established to reset the appropriate Kanban level. In recent years manufacturers have touted a trailing 13 week average is a better predictor than most forecastors could provide.
For More info refer
http://en.wikipedia.org/wiki/Just_In_Time
Kaizen (改善, Japanese for "change for the better" or "improvement") is an approach to productivity improvement originating in applications of the work of American experts such as Frederick Winslow Taylor, Frank Bunker Gilbreth, Walter Shewhart,and of the War Department's Training Within Industry program by post-WWII Japanese manufacturers. The development of Kaizen went hand-in-hand with that of Quality control circles, but it was not limited to quality assurance.
The goals of kaizen include the elimination of waste (defined as "activities that add cost but do not add value"), just-in-time delivery, production load leveling of amount and types, standardized work, paced moving lines, right-sized equipment, and others. A closer definition of the Japanese usage of Kaizen is "to take it apart and put back together in a better way." What is taken apart is usually a process, system, product, or service.
Kaizen is a daily activity whose purpose goes beyond improvement. It is also a process that when done correctly humanizes the workplace, eliminates hard work (both mental and physical), teaches people how to do rapid experiments using the scientific method, and how to learn to see and eliminate waste in business processes.
"Kaizen" is the correct usage. "Kaizen event" or "kaizen blitz" are incorrect usage.
Kaizen is often misunderstood and applied incorrectly, resulting in bad outcomes including, for example, layoffs. This is called "kaiaku" - literally, "change for the worse." Layoffs are not the intent of kaizen. Instead, kaizen must be practiced in tandem with the "Respect for People" principle. Without "Respect for People," there can be no continuous improvement. Instead, the usual result is one-time gains that quickly fade.
Importantly, kaizen must operate with three principles in place: process and results (not results-only); systemic thinking (i.e. big picture, not solely the narrow view); and non judgmental, non-blaming (because blaming is wasteful).
Everyone participates in kaizen; people of all levels in an organization, CEO on down, as well as external stakeholders if needed. The format for kaizen can be individual, suggestion system, small group, or large group.
The only way to truly understand the intent, meaning, and power of kaizen is through direct participation - many, many times.
Lean accounting and just in time producton are related concepts.
Process Models
A decades-long goal has been to find repeatable, predictable processes or methodologies (software engineering) that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management is proving difficult.
Waterfall processes
The best-known and oldest process is the waterfall model, where developers (roughly) follow these steps in order. They state requirements, analyze them, design a solution approach, architect a software framework for that solution, develop code, test (perhaps unit tests then system tests), deploy, and maintain. After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected. If iteration is not included in the planning, the process has no provision for correcting errors in early steps (for example, in the requirements), so the entire (expensive) engineering process may be executed to the end, resulting in unusable or unneeded software features.
In old style (CMM) processes, architecture and design preceded coding, usually by separate people in a separate process step.
Iterative processes
Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what he wants.
Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.
Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability. In essence, they say that they will provide the most bang for the buck, but won't say exactly when that bang will be.
Extreme Programming, XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.
While Iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of upfront analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, Iterative development can create long term challenges that are significant in terms of cost and quality.
Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer. The approach can also be very expensive, akin to... "If you don't know what kind of house you want, let me build you one and see if you like it. If you don't, we'll tear it all down and start over." A large pile of building-materials, which are now scrap, can be the final result of such a lack of up-front discipline.
Formal methods
Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behaviour by designing a system of finite state machines.
Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine).
Recent approaches try to merge the specification and code into one activity to ensure the specification and code match. While Agile methods propagate specification of all requirements in code, methods such as VFSM develop executable specifications, trying to avoid the coding activity entirely
Quality control tools
The following are the mostwidely used Quality control tools
Run Chart :Run charts are used to analyze processes according to time or order. Run charts are useful in discovering patterns that occur over time. Detailed tutorial
Pareto Chart :Pareto charts are extremely useful because they can be used to identify those factors that have the greatest cumulative effect on the system, and thus screen out the less significant factors in an analysis. Ideally, this allows the user to focus attention on a few important factors in a process.
Flow Chart :Flowcharts are pictorial representations of a process. By breaking the process down into its constituent steps, flowcharts can be useful in identifying where errors are likely to be found in the system. Detailed tutorial
Cause and Effect Diagram :Thisdiagram, also called an Ishikawa diagram (or fish bone diagram), is used to associate multiple possible causes with a single effect. Thus, given a particular effect, the diagram is constructed to identify and organize possible causes for it. Detailed tutorial
Histogram :Histograms provide a simple, graphical view of accumulated data, including its dispersionand central tendancy. In addition to the ease with which they can beconstructed, histograms provide the easiest way to evaluate the distribution ofdata. Detailed tutorial
Scatter diagrams : Scatter diagramsare graphical tools that attempt to depict the influence that one variable has on another. A common diagram of this type usually displays points representing the observed value of one variable corresponding to the value of another variable. Detailed tutorial
Control Chart :The control chart is the fundamental tool of statistical process control, as it indicates the range of variability that is built into a system (known as common cause variation). Thus, it helps determine whether or not a process is operating consistently or if a special cause has occurred to change the process mean or variance.
Requirements Management and Enterprise Architecture
Requirements Management is the science and art of gathering and managing user, business, technical, functional requirements, and process requirements within a product development project. The project could be for a new consumer product, a web site, a system or a software application. In all these cases, the five classes of requirements should be represented.
The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.
Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).
Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.For ease of use, it is convenient to think of requirements as belonging to a type.
The objective of the Requirements Management activity is to define a process whereby requirements for Enterprise Architecture are identified, stored, and fed into and out of the relevant Enterprise Architecture development phases. As such it forms part of the activities and steps carried out in each of these phases though it is not referred to implicitly in any projects I have managed.
Requirements Management is also a discipline for both Quality Management (ISO 90001:2000) and Project Management (PMI)).
Target architecture must be based on credible assumptions about future business requirements. Getting these future requirements is not a simple matter of asking business management for them, and analyzing them is not the linear technique used to develop the design for a project. Instead, we have to use a combination of requirements aggregation and scenarios to gather and analyze long-term requirements. This will lead to more credible architectures with appropriate flexibility and evident business value.For ease of use, it is convenient to think of requirements as belonging to a type.
They are the fundamental or essential subject matter of the service or product. They describe what the service or product has to do or what processing actions it is to take.
Business Cases or Scenarios should be used as a useful technique to discover and document these requirements.
Project and Portfolio Management (PPM) addresses the decisions regarding what projects to undertake, with what priority, and in what sequence. Before a project has gone through the necessary requirements definition activities, its scope is based on high-level requirements derived from business drivers, plans, and needs. If these requirements are viewed in isolation, then solutions will be defined in isolation, and they will ignore synergies or dependencies between projects and undervalue foundational projects that provide capabilities that can be leveraged across future projects. Business Requirements also have to be a source for Project Management methodologies.
They are the properties that the functions must have, such as performance and usability. These requirements are as important as the functional requirements for the product/service’s success.
These are restrictions on projects due to the budget or the time available to build a product or service.
They impose restrictions on how the product/service must be designed. For example, it might have to be implemented in the hand-held device being given to major customers, or it might have to use the existing servers and desktop computers, or any other hardware, software, or business practice.
These are the business-related forces. For example, the purpose of the project is a project driver, as are all of the stakeholders-each for different reasons.
They define the conditions under which the project will be done. The reason for including them as part of the requirements is to present a coherent picture of all factors that contribute to the success or failure of the project and to illustrate how managers can use requirements as input when managing a project.
It is recommended to start testing requirements as soon as we start writing them.We make a requirement testable by adding its fit criterion. This fit criterion measures the requirement, making it possible to determine whether a given solution fits the requirement. If a fit criterion cannot be found for a requirement, then the requirement is either ambiguous or poorly understood. All requirements can be measured, and all should carry a fit criterion.
http://sergethorn.blogspot.com/2007/12/requirements-management-and-enterprise.html
Six Sigma - Terms and Definitions
Jack Welch, former CEO of General Electric, and one of the most succesful corporate leaders ever, used Six Sigma as major Quality Improvement method.
In his book Winning he writes:
Six Sigma is one the biggest management innovations of the past 25 years. Six Sigma improves the development procedures, brings products faster to the market with less defects, and reduces cost. The biggest - but least praised - advantage of Six Sigma is its potential to cultivate excellent leaders.
Six Sigma is not about averages, it is about eliminating variances from your relationship with the customers.
Six Sigma Definitions from the the GE website:
Quality Approaches and
ModelsDFSS –(Design for Six Sigma) is a systematic methodology utilizing tools, training and measurements to enable us to design products and processes that meet customer expectations and can be produced at Six Sigma quality levels.
DMAIC – (Define, Measure, Analyze, Improve and Control) is a process for continued improvement. It is systematic, scientific and fact based. This closed-loop process eliminates unproductive steps, often focuses on new measurements, and applies technology for improvement.
Six Sigma – A vision of quality which equates with only 3.4 defects per million opportunities for each product or service transaction. Strives for perfection.
Quality Tools
Associates are exposed to various tools and terms related to quality. Below are just a few of them.
Control Chart – Monitors variance in a process over time and alerts the business to unexpected variance which may cause defects.
Defect Measurement – Accounting for the number or frequency of defects that cause lapses in product or service quality.
Pareto Diagram – Focuses on efforts or the problems that have the greatest potential for improvement by showing relative frequency and/or size in a descending bar graph. Based on the proven
Pareto principle: 20% of the sources cause 80% of any problems.
Process Mapping – Illustrated description of how things get done, which enables participants to visualize an entire process and identify areas of strength and weaknesses. It helps reduce cycle time and defects while recognizing the value of individual contributions.
Root Cause Analysis – Study of original reason for nonconformance with a process. When the root cause is removed or corrected, the nonconformance will be eliminated.
Statistical Process Control – The application of statistical methods to analyze data, study and monitor process capability and performance.
Tree Diagram – Graphically shows any broad goal broken into different levels of detailed actions. It encourages team members to expand their thinking when creating solutions.Quality TermsBlack Belt – Leaders of team responsible for measuring, analyzing, improving and controlling key processes that influence customer satisfaction and/or productivity growth. Black Belts are full-time positions.
Control – The state of stability, normal variation and predictability. Process of regulating and guiding operations and processes using quantitative data.
CTQ: Critical to Quality (Critical "Y") – Element of a process or practice which has a direct impact on its perceived quality.Customer Needs,
Expectations – Needs, as defined by customers, which meet their basic requirements and standards.
Defects – Sources of customer irritation. Defects are costly to both customers and to manufacturers or service providers. Eliminating defects provides cost benefits.
Green Belt – Similar to Black Belt but not a full-time position.
Master Black Belt – First and foremost teachers. They also review and mentor Black Belts. Selection criteria for Master Black Belts are quantitative skills and the ability to teach and mentor. Master Black Belts are full-time positions.
Variance – A change in a process or business practice that may alter its expected outcome.
Six Sigma aims at repeating internal processes and complex new product developments. Forced application of Six Sigma in creative activities does not make a lot of sense and cause a lot of commotion.
Did you apply Six Sigma in Software Development ? Was it the Silver Bullet or a bureaucratic metrics nightmare ?
In his book Winning he writes:
Six Sigma is one the biggest management innovations of the past 25 years. Six Sigma improves the development procedures, brings products faster to the market with less defects, and reduces cost. The biggest - but least praised - advantage of Six Sigma is its potential to cultivate excellent leaders.
Six Sigma is not about averages, it is about eliminating variances from your relationship with the customers.
Six Sigma Definitions from the the GE website:
Quality Approaches and
ModelsDFSS –(Design for Six Sigma) is a systematic methodology utilizing tools, training and measurements to enable us to design products and processes that meet customer expectations and can be produced at Six Sigma quality levels.
DMAIC – (Define, Measure, Analyze, Improve and Control) is a process for continued improvement. It is systematic, scientific and fact based. This closed-loop process eliminates unproductive steps, often focuses on new measurements, and applies technology for improvement.
Six Sigma – A vision of quality which equates with only 3.4 defects per million opportunities for each product or service transaction. Strives for perfection.
Quality Tools
Associates are exposed to various tools and terms related to quality. Below are just a few of them.
Control Chart – Monitors variance in a process over time and alerts the business to unexpected variance which may cause defects.
Defect Measurement – Accounting for the number or frequency of defects that cause lapses in product or service quality.
Pareto Diagram – Focuses on efforts or the problems that have the greatest potential for improvement by showing relative frequency and/or size in a descending bar graph. Based on the proven
Pareto principle: 20% of the sources cause 80% of any problems.
Process Mapping – Illustrated description of how things get done, which enables participants to visualize an entire process and identify areas of strength and weaknesses. It helps reduce cycle time and defects while recognizing the value of individual contributions.
Root Cause Analysis – Study of original reason for nonconformance with a process. When the root cause is removed or corrected, the nonconformance will be eliminated.
Statistical Process Control – The application of statistical methods to analyze data, study and monitor process capability and performance.
Tree Diagram – Graphically shows any broad goal broken into different levels of detailed actions. It encourages team members to expand their thinking when creating solutions.Quality TermsBlack Belt – Leaders of team responsible for measuring, analyzing, improving and controlling key processes that influence customer satisfaction and/or productivity growth. Black Belts are full-time positions.
Control – The state of stability, normal variation and predictability. Process of regulating and guiding operations and processes using quantitative data.
CTQ: Critical to Quality (Critical "Y") – Element of a process or practice which has a direct impact on its perceived quality.Customer Needs,
Expectations – Needs, as defined by customers, which meet their basic requirements and standards.
Defects – Sources of customer irritation. Defects are costly to both customers and to manufacturers or service providers. Eliminating defects provides cost benefits.
Green Belt – Similar to Black Belt but not a full-time position.
Master Black Belt – First and foremost teachers. They also review and mentor Black Belts. Selection criteria for Master Black Belts are quantitative skills and the ability to teach and mentor. Master Black Belts are full-time positions.
Variance – A change in a process or business practice that may alter its expected outcome.
Six Sigma aims at repeating internal processes and complex new product developments. Forced application of Six Sigma in creative activities does not make a lot of sense and cause a lot of commotion.
Did you apply Six Sigma in Software Development ? Was it the Silver Bullet or a bureaucratic metrics nightmare ?
Handling Late Requirements
Many of project issues are related to bad requirements management. One particular issue which is hard to tackle is the handling of late requirements.
Coping with new requirements after the development has started often leads to problems in the project:
Coping with new requirements after the development has started often leads to problems in the project:
- Schedule, cost and scope of the running project become unknown
delays due to unsufficient impact investigation, which may propagate to other projects in the program. - Rework of finished development
- Quality problems, unsufficient time left for testing
- Lost accountability of the development team
- Drifting morale
Before starting with the implementation of late requirement, do a feasability study including an impact analysis on the cost, schedule, and scope of the project.
The following alternative solutions can be offered for development to handle the late requirements:
- Define a separate update release for the late requirements
- Leave room in the original plan to handle late requirements
- Prioritise requirements, leave some priority 2 requirements out to make room for the new requirements. Apply this technique Only when effort is not too big,
ie. Less than 10% project size, and if you have good configuration management practices to take code out again after coding has started.
Late requirements do not have to end with project chaos, they can be handled in a disciplined and controlled way.
Requirement Processes
Understand and communicate requirements that align out IT priorities with your business needs.
No process is more fundamental than the process of defining and managing business and technical requirements. It's no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.
The Requirements-engineering process consists of two major domains:
Definition and Management.
Best practices:
Elicit Requiremements:
Define the vision and project scope.
Identify the appropriate stakeholders.
Select champions (Voice of the customer).
Choose elicitation techniques (workshops, questionnaires, surveys, individual interviews).
Explore user scenarios.
Analyse Requirements:
Verify they are complete and achievable
Create analysis models.
Build and evaluate prototypes.
Prioritize requirements.
Specify Requirements:
Look for ambiguities.
Store requirements in a database.
Trace requirements into design, code, and tests.
Validate Requirements:
Review the requirements through a formal peer review.
Create test cases from requirements.
Manage Requirements:
Manage versions.
Adopt a change control process.
Perform requirements change impact analysis.
Store requirements attributes.
Track the status of each requirement.
Applying requirements best practices lead to higher satisfaction for your customers.
Matts Klassen's article: Achieve Useful Requirements Processes.
No process is more fundamental than the process of defining and managing business and technical requirements. It's no surprise that studies cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.
The Requirements-engineering process consists of two major domains:
Definition and Management.
Best practices:
Elicit Requiremements:
Define the vision and project scope.
Identify the appropriate stakeholders.
Select champions (Voice of the customer).
Choose elicitation techniques (workshops, questionnaires, surveys, individual interviews).
Explore user scenarios.
Analyse Requirements:
Verify they are complete and achievable
Create analysis models.
Build and evaluate prototypes.
Prioritize requirements.
Specify Requirements:
Look for ambiguities.
Store requirements in a database.
Trace requirements into design, code, and tests.
Validate Requirements:
Review the requirements through a formal peer review.
Create test cases from requirements.
Manage Requirements:
Manage versions.
Adopt a change control process.
Perform requirements change impact analysis.
Store requirements attributes.
Track the status of each requirement.
Applying requirements best practices lead to higher satisfaction for your customers.
Matts Klassen's article: Achieve Useful Requirements Processes.
6 Tips for Quickening Software Releases
MONTHLY NEWSLETTER
January 2008 - Pragmatic Software Newsletters
Tools for Managing the Software Development Lifecycle
Sponsored Link
http://www.softwareplanner.com/Software Planner is an award winning web-based solution for managing the software life cycle. Tracks support tickets, customer requirements, defects, test cases and allows document sharing. Provides project management, with importing/exporting from Microsoft Project®, customizable dashboards and Microsoft Outlook® Synchronization.Awards: Best ALM/QA Tool . Best Project Management Solution . Best Bug and Defect Tracking Tool SD Times Top 100. Best Performance/Test Tool
6 Tips for Quickening Software Releases
Many of us have experienced projects that drag on much longer than expected and cost more than planned. Most times, this is caused either from inadequate planning (requirement collection and design) or from an inordinate number of defects found during the testing cycle.
A major ingredient to reducing development life cycle time is to eliminate defects before they happen. By reducing the number of defects that are found during your quality assurance testing cycle, your team can greatly reduce the time it takes to implement your software project. Below are some tips to aid in reducing software defects:
Tip 1 - Deliver Releases in Iterations: When collecting requirements, it is best to identify the priority of each feature for a release. By prioritizing features as High/Medium/Low, your team can include only the high priorities in the first iteration of the software, then can move to the medium and lower priority items in future iterations.
An iteration is a set of features that are bundled into a release that could be launched to production, if desired. Agile scrum developers refer to these as sprints. By implementing features in iterations, it allows you to begin using the software earlier, flesh out requirements that did not pan out as well as thought, and to discover any technology glitches that may have been found at a later date.
Tip 2 - Conduct Requirement Walkthroughs: The best time to stop defects is before coding begins.
As the project manager or requirements manager begins collecting the requirements for the software, they should hold meetings with two or more developers to ensure that the requirements are not missing information or are not flawed from a technical perspective.
These meetings can bring to surface easier ways to accomplish the requirement and can save countless hours in development if done properly.
As a rule of thumb, the requirements should be fully reviewed by the developers before the requirements are signed off.
Tip 3 - Distribute Test Cases to Programmers Before Coding Begins:
Once a requirement is fully defined and approved, your Quality Assurance team should create a full suite of test cases for the requirement. Once this is done (and before coding begins), publish those test cases to the programmer that is developing the code.
Ensure that your project manager adds a task for the programmer to run each test case prior to delivering it to the test team for testing.
This approach may add a few hours (or a few days) to the programmer's task list but will pay dividends by reducing the number of defects found and improving the quality of the release. By following this approach, you can expect 70% - 80% less defects and can reduce the quality assurance time by 75% or more.
Tip 4 - Review Burn Down Statistics :
Burn down statistics are simply a way of analyzing how much effort is remaining in a release.
For example, if you begin a project that has 5 full time resources working 40 hours a week, you can assume that 200 hours of work per week will be accomplished. If you are planning a release that will take 4 weeks, your team of 5 should be able to deliver 800 hours of work.
Each day, each team member should record the number of hours worked against tasks, and the number of hours remaining to complete their tasks. By recording the number of hours remaining, you can determine if you will finish on time or not (this also helps validate your estimates).
Each day, you can compare how many hours are remaining versus how many hours should be remaining. If you have more hours remaining that hours that should be remaining, you can help your team by adding additional resources, reducing feature set, or by asking for overtime work.
As your project begins getting closer toward delivery, your burn down (hours remaining) should decline.
Tip 5 - Conduct Code Reviews: Once coding begins, each programmer should be encouraged to conduct weekly code reviews with their peers.
The meeting is relatively informal, where the programmer distributes source code listings to a couple of his/her peers. The peers should inspect the code for logic errors, reusability and conformance to requirements.
This process should take no more than an hour and if done properly, will prevent many defects that could arise later in testing. Every few weeks (or before a minor release), the chief architect or technical team leader should do a formal inspection of their team's code. This review is a little more formal, where the leader reviews the source code listings for logic errors, reusability, adherence to requirements, integration with other areas of the system, and documentation.
Using a checklist will ensure that all areas of the code are inspected. This process should take no more than a couple of hours for each programmer and should provide specific feedback and ideas for making the code work per the design.As inspections are held, someone (referred to as a scribe) should attend the meetings and make detailed notes about each item that is found. Once the meeting is over, the scribe will send the notes to each team member, ensuring that all items are addressed.
The scribe can be one of the other programmers, an administrative assistant, or anyone on the team. The defects found should be logged using your defect tracking system and should note what phase of the life cycle the defect was found.
Tip 6 - Collect Metrics: Collect statistics that show how many defects (along with severity and priority) are found in the different stages of the life cycle. The statistics will normally show over time that when more defects are resolved earlier in the life cycle, the length of the project decreases and the quality increases.
Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:
Project Management Templates
Pragmatic Agile Development (PAD) Overview - http://www.PragmaticSW.com/PADOverviewPresentation.pdf
PAD Road Map - http://www.PragmaticSW.com/Pragmatic/Templates/RoadMap_Template.pdf
PAD Best Practices Excerpt - http://www.PragmaticSW.com/PADBestPracticesExcerpt.pdf
Additional PAD Information - http://www.pragmaticsw.com/PADOverview.pdf
Project Management Guidelines - http://www.PragmaticSW.com/Pragmatic/Templates/ProjectMgtGuidelines.rtf
Architectural Overview - http://www.PragmaticSW.com/Pragmatic/Templates/ArchitectureOverview.rtf
Risk Assessment - http://www.PragmaticSW.com/Pragmatic/Templates/Risk%20Assessment.rtf
Post Mortem Report - http://www.PragmaticSW.com/Pragmatic/Templates/PostMortem.rtf
Quality Assurance Templates
Functional Specifications - http://www.PragmaticSW.com/Pragmatic/Templates/FunctionalSpec.rtf
Detailed Design - http://www.PragmaticSW.com/Pragmatic/Templates/DetailedDesign.rtf
Test Design - http://www.PragmaticSW.com/Pragmatic/Templates/TestDesign.rtf
Weekly Status - http://www.PragmaticSW.com/Pragmatic/Templates/WeeklyStatusRpt.rtf
User Acceptance Test Release Report - http://www.PragmaticSW.com/Pragmatic/Templates/UATRelease.rtf
Other Helpful Links
Prior Newsletters - http://www.PragmaticSW.com/Newsletters.asp
Software Planner - http://www.SoftwarePlanner.com/SoftwarePlanner.asp
Defect Tracker - http://www.defecttracker.com/
About the AuthorSteve Miller is the President of Pragmatic Software (http://www.pragmaticsw.com/). With over 23 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software. You can read other newsletters at http://www.PragmaticSW.com/Newsletters.asp. Steve's email is steve.miller@PragmaticSW.com.
January 2008 - Pragmatic Software Newsletters
Tools for Managing the Software Development Lifecycle
Sponsored Link
http://www.softwareplanner.com/Software Planner is an award winning web-based solution for managing the software life cycle. Tracks support tickets, customer requirements, defects, test cases and allows document sharing. Provides project management, with importing/exporting from Microsoft Project®, customizable dashboards and Microsoft Outlook® Synchronization.Awards: Best ALM/QA Tool . Best Project Management Solution . Best Bug and Defect Tracking Tool SD Times Top 100. Best Performance/Test Tool
6 Tips for Quickening Software Releases
Many of us have experienced projects that drag on much longer than expected and cost more than planned. Most times, this is caused either from inadequate planning (requirement collection and design) or from an inordinate number of defects found during the testing cycle.
A major ingredient to reducing development life cycle time is to eliminate defects before they happen. By reducing the number of defects that are found during your quality assurance testing cycle, your team can greatly reduce the time it takes to implement your software project. Below are some tips to aid in reducing software defects:
Tip 1 - Deliver Releases in Iterations: When collecting requirements, it is best to identify the priority of each feature for a release. By prioritizing features as High/Medium/Low, your team can include only the high priorities in the first iteration of the software, then can move to the medium and lower priority items in future iterations.
An iteration is a set of features that are bundled into a release that could be launched to production, if desired. Agile scrum developers refer to these as sprints. By implementing features in iterations, it allows you to begin using the software earlier, flesh out requirements that did not pan out as well as thought, and to discover any technology glitches that may have been found at a later date.
Tip 2 - Conduct Requirement Walkthroughs: The best time to stop defects is before coding begins.
As the project manager or requirements manager begins collecting the requirements for the software, they should hold meetings with two or more developers to ensure that the requirements are not missing information or are not flawed from a technical perspective.
These meetings can bring to surface easier ways to accomplish the requirement and can save countless hours in development if done properly.
As a rule of thumb, the requirements should be fully reviewed by the developers before the requirements are signed off.
Tip 3 - Distribute Test Cases to Programmers Before Coding Begins:
Once a requirement is fully defined and approved, your Quality Assurance team should create a full suite of test cases for the requirement. Once this is done (and before coding begins), publish those test cases to the programmer that is developing the code.
Ensure that your project manager adds a task for the programmer to run each test case prior to delivering it to the test team for testing.
This approach may add a few hours (or a few days) to the programmer's task list but will pay dividends by reducing the number of defects found and improving the quality of the release. By following this approach, you can expect 70% - 80% less defects and can reduce the quality assurance time by 75% or more.
Tip 4 - Review Burn Down Statistics :
Burn down statistics are simply a way of analyzing how much effort is remaining in a release.
For example, if you begin a project that has 5 full time resources working 40 hours a week, you can assume that 200 hours of work per week will be accomplished. If you are planning a release that will take 4 weeks, your team of 5 should be able to deliver 800 hours of work.
Each day, each team member should record the number of hours worked against tasks, and the number of hours remaining to complete their tasks. By recording the number of hours remaining, you can determine if you will finish on time or not (this also helps validate your estimates).
Each day, you can compare how many hours are remaining versus how many hours should be remaining. If you have more hours remaining that hours that should be remaining, you can help your team by adding additional resources, reducing feature set, or by asking for overtime work.
As your project begins getting closer toward delivery, your burn down (hours remaining) should decline.
Tip 5 - Conduct Code Reviews: Once coding begins, each programmer should be encouraged to conduct weekly code reviews with their peers.
The meeting is relatively informal, where the programmer distributes source code listings to a couple of his/her peers. The peers should inspect the code for logic errors, reusability and conformance to requirements.
This process should take no more than an hour and if done properly, will prevent many defects that could arise later in testing. Every few weeks (or before a minor release), the chief architect or technical team leader should do a formal inspection of their team's code. This review is a little more formal, where the leader reviews the source code listings for logic errors, reusability, adherence to requirements, integration with other areas of the system, and documentation.
Using a checklist will ensure that all areas of the code are inspected. This process should take no more than a couple of hours for each programmer and should provide specific feedback and ideas for making the code work per the design.As inspections are held, someone (referred to as a scribe) should attend the meetings and make detailed notes about each item that is found. Once the meeting is over, the scribe will send the notes to each team member, ensuring that all items are addressed.
The scribe can be one of the other programmers, an administrative assistant, or anyone on the team. The defects found should be logged using your defect tracking system and should note what phase of the life cycle the defect was found.
Tip 6 - Collect Metrics: Collect statistics that show how many defects (along with severity and priority) are found in the different stages of the life cycle. The statistics will normally show over time that when more defects are resolved earlier in the life cycle, the length of the project decreases and the quality increases.
Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:
Project Management Templates
Pragmatic Agile Development (PAD) Overview - http://www.PragmaticSW.com/PADOverviewPresentation.pdf
PAD Road Map - http://www.PragmaticSW.com/Pragmatic/Templates/RoadMap_Template.pdf
PAD Best Practices Excerpt - http://www.PragmaticSW.com/PADBestPracticesExcerpt.pdf
Additional PAD Information - http://www.pragmaticsw.com/PADOverview.pdf
Project Management Guidelines - http://www.PragmaticSW.com/Pragmatic/Templates/ProjectMgtGuidelines.rtf
Architectural Overview - http://www.PragmaticSW.com/Pragmatic/Templates/ArchitectureOverview.rtf
Risk Assessment - http://www.PragmaticSW.com/Pragmatic/Templates/Risk%20Assessment.rtf
Post Mortem Report - http://www.PragmaticSW.com/Pragmatic/Templates/PostMortem.rtf
Quality Assurance Templates
Functional Specifications - http://www.PragmaticSW.com/Pragmatic/Templates/FunctionalSpec.rtf
Detailed Design - http://www.PragmaticSW.com/Pragmatic/Templates/DetailedDesign.rtf
Test Design - http://www.PragmaticSW.com/Pragmatic/Templates/TestDesign.rtf
Weekly Status - http://www.PragmaticSW.com/Pragmatic/Templates/WeeklyStatusRpt.rtf
User Acceptance Test Release Report - http://www.PragmaticSW.com/Pragmatic/Templates/UATRelease.rtf
Other Helpful Links
Prior Newsletters - http://www.PragmaticSW.com/Newsletters.asp
Software Planner - http://www.SoftwarePlanner.com/SoftwarePlanner.asp
Defect Tracker - http://www.defecttracker.com/
About the AuthorSteve Miller is the President of Pragmatic Software (http://www.pragmaticsw.com/). With over 23 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software. You can read other newsletters at http://www.PragmaticSW.com/Newsletters.asp. Steve's email is steve.miller@PragmaticSW.com.
Subscribe to:
Posts (Atom)