knowledge
- 11:04 PM - 0 comments
Software Project Planning Practices
i) Software Project Plan
The project plan is used by many people in the organization.
Person In-Charge | Description |
Project Manager |
|
Team Member |
|
Senior Manager |
|
stakeholder |
|
A typical project plan consists of:
- A statement of work (SOW) that describes all work products (specifications, test plans, code, defect reports and any other product of work performed over the course of the project) that will be produced and a list of people who will perform that work
- A resource list that contains a list of all resources that will be needed for the product and their availability
- A work breakdown structure (WBS) and a set of effort estimates
- A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled should they occur
ii) Project Schedule
The project schedule is the core of the project plan. It is used by the project manager to commit people to the project and show the organization how the work will be performed. Schedules are used to communicate final deadlines and, in some cases, to determine resource needs. They are also used as a kind of checklist to make sure that every task necessary is performed. If a task is on the schedule, the team is committed to doing it. In other words, the project schedule is the means by which the project manager brings the team and the project under control.
Before a project schedule can be created, the project manager must have a work breakdown structure (WBS), an effort estimate for each task, and a resource list with availability for each resource. A project manager’s time is better spent on working with the team to create a WBS and estimates (using a consensus-driven estimation method like Wideband Delphi) than on trying to build a project schedule without them. The reason for this is that a schedule itself is an estimate: each date in the schedule is estimated, and if those dates do not have the buy-in of the people who are going to do the work, the schedule will almost certainly be inaccurate.
Other project scheduling software packages include:
Estimation method and Management tool
a) WBS is a list of tasks that, if completed, will produce the final product. The
project can be broken down by feature, by project phase (requirements tasks, design tasks, programming tasks, QA tasks, etc.), or by some combination of the two. No estimate is guaranteed to be accurate. People get sick or leave the organization; teams
run into unforeseen technical problems; the needs of the organization change.
b) The Wideband Delphi estimation adapted across many industries to estimate many kinds of tasks, ranging from statistical data collection results to sales and marketing forecasts. It has proven to be a very effective estimation tool, and it lends itself well to software projects. It is useful to a project manager because it produces several important elements of the project plan. The most important product is the set of estimates upon which the project schedule is built.
c) Open Workbench is an open source desktop application that provides robust project scheduling and management functionality. Already the scheduling standard for more than 100,000 project managers worldwide, Open Workbench is a free and powerful alternative to Microsoft Project.
d) dotProject is a volunteer supported Project Management application. There is no "company" behind this project, it is managed, maintained, developed and supported by a volunteer group and by the users themselves.
e) netOffice is a web based project management tools written in PHP and utilizing MySQL. It has a surprisingly easy to use user interface, and it really is self explanatory, even for first time users. It has the same features as most other free web based project management tools but is set apart from the pack by its simple layout and amazing ease of use.
f) TUTOS (The Ultimate Team Organization Software) is a groupware, ERP (Enterprise Resource Planing), CRM (Customer Relationship Management), and PLM (Project Lifecycle Management) suite that helps small to medium teams manage various things in one place. Its features include personal and group calendars, an address book, product and project management, bug tracking, installation management, a task list, notes, files, mailboxes, and useful links between all of the above.
iii) Risk Plan
Risk assessment is an important part of planning a software project because it allows the project manager to predict potential problems that will threaten the project and take steps to mitigate those problems. Adding a risk plan to a software project plan is an effective way to keep the project from being derailed by surprises or emergencies.
The risk planning meeting happens in three parts: a brainstorming session to identify risks; a discussion where the probability and impact of each risk is estimated; and a discussion to identify actions that can mitigate risks. The end result is a risk management plan, which should be included verbatim in the final project plan.
iv) Change Control
Change control is method for implementing only changes that are worth pursuing, and for preventing unnecessary or overly costly changes from derailing the project. Change control is essentially an agreement between the project team and the managers that are responsible for decision-making on the project to evaluate the impact of a change before implementing it. Many changes that initially sound like good ideas will get thrown out once the true cost of the change is known. The potential benefit of the change is written down, and the project manager works with the team to estimate the potential impact that the change will have on the project. This gives the organization all of the information necessary to do a real cost-benefit analysis. If the benefit of the change is worth the cost, the project manager updates the plan to reflect the new estimates. Otherwise, the change is thrown out and the team continues with the original plan.
The most important part of change control is a change control board (CCB). There are certain people in the organization who have the power to change the scope of the project. Usually there is a senior manager or decision-maker who has the authority to make sweeping changes at will; sometimes there are several people in this position. For change control to be effective, these people must be part of the CCB.
The CCB should contain people from the project team:
· The project manager
· An important stakeholder or user (or someone who understands and advocates their perspective)
· Someone who understands the effort involved in making the change (usually, this is a representative from the programming team)
· Someone who understands the engineering decisions that the team makes over the course of the project (a design team member, requirements analyst or, if neither is available, a programmer who participated in the design of the software)
· Someone who is familiar with the expected functionality of the software and with the behavior being discussed for each individual change (typically a tester)
http://www.stellman-greene.com/aspm/content/blogcategory/15/38/
0 Responses to "Software Project Planning Practices"
Post a Comment