No	Field of Allocation	Cost
1	Software Construction Installation,Develop,Configuration,Testing,Prototype, Audits	$ 30 000.00
2	Hardware Requirements Computers,Printers,Tools,Devices	$ 10 000.00
3	Software Requirements Database systems,Servers,Internet/Intranet,Security and Controls	$ 20 000.00
3	Manpower Payroll Gross Salary for 5 months duration of Software Production team expertise,Welfare & Safety Insurance	$ 50 000.00
4	Maintenance Delivery,Technical and Customer Support,Maintenance Services	$ 20 000.00
5	Research & Design Requirements,Analysis,Feasibility Study	$ 10 000.00
6	Documentation User Manual,Reports,Invoices,Receipts,Records,Contracts	$ 10 000.00
TOTAL		$ 150 000.00

i) Software Project Plan

The project plan is used by many people in the organization.

Person In-Charge	Description
Project Manager	Communicate the project’s status to the stakeholders and senior managers Plan the team’s activities
Team Member	Understand the context for the work they are doing
Senior Manager	Verify that the project’s cost and schedule are reasonable and under control
stakeholder	Make sure that the project is on track Their needs are being addressed

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 project schedule

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

• Open Workbench
• dotProject
• netOffice
• TUTOS

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/

Risk is defined as "The possibility of suffering harm or loss; danger." Even if we're not familiar with the formal definition, most of us have an innate sense of risk. We are aware of the potential dangers that permeate even simple daily activities, from getting injured when crossing the street to having a heart attack because our cholesterol level is too high. Although we prefer not to dwell on the myriad of hazards that surround us, these risks shape many of our behaviors. Experience (or a parent) has taught us to look both ways before stepping off the curb and most of us at least think twice before ordering a steak. Indeed, we manage personal risks every day.
Risks in Software Project Management

Unlike the hazards of daily living, the dangers in the young and emerging field of software engineering must often be learned without the benefit of lifelong exposure. A more deliberate approach is required. Such an approach involves studying the experiences of successful project managers as well as keeping up with the leading writers and thinkers in the field. One such writer in the area of risk is Dr. Barry W. Boehm. In his article "Software Risk Management: Principles and Practices" he lists the following top 10 software risk items:

1. Personnel Shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong functions and properties
4. Developing the wrong user interface
5. Gold-plating
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer-science capabilities

How to Manage

In the same article, Dr. Boehm describes risk management as being comprised of the following activities:

* Risk Assessment (figuring out what the risks are and what to focus on)

• making a list of all of the potential dangers that will affect the project
• assessing the probability of occurence and potential loss of each item listed
• ranking the items (from most to least dangerous)

* Risk Control (doing something about them)

• coming up with techniques and strategies to mitigate the highest ordered risks
• implementing the strategies to resolve the high order risks factors
• monitoring the effectiveness of the strategies and the changing levels of risk
  throughout the project