Monday, 11 July 2011

Essential Elements of Software Project Management

Choose the Project Methodology: A key decision is the methodology that will be used for your project. A traditional waterfall methodology is highly structured to deliver good results, but can result in longer projects based on its sequential set of tasks. Agile methodologies deliver quicker results, but require managing cross-functional teams and allowing them more freedom to create prototypes in several iterations as requirements are refined.


Identify Requirements: A solid understanding of user requirements forms the foundation for your software, yet there's often a rush to skip this and move to the coding phase. This may cause you to miss necessary requirements or try to meet an ever-changing target as new requirements are uncovered.


Understand the Technology: It's crucial that the project manager understands the maturity level of the technology used for the project, since technology changes at a rapid pace. If it's a well-understood technology, the chance of meeting the project schedule is high.


Communicate with Business Stakeholders: Technical jargon is a foreign language to most business stakeholders, so communication between the project manager, the technical team and other stakeholders can be a challenge. Project managers and technical team members need to talk about the requirements and project risks using business terminology. If users can't understand the explanation, they can't make informed decisions about the level of risk they're willing to accept.


Deliver Phased Results: Many software projects are large, expensive and lengthy efforts. Often the new software isn't delivered until months or years after the requirements were originally documented.


Understand the Culture: Project managers should consider cultural issues in the project planning. This includes adding contingency time in the schedule to work through possible issues and clearly communicating the risks of taking short cuts.

Sunday, 26 June 2011

Project Management Institute

The nine areas of project management outlined by Project Management Institute (PMI) are:


(1) Project Scope Management:
Controlling the planning, execution, and content of the project.
 • We need to pay special attention to both project & product scope so that the software we end up with its what we intended to make in the first place


(2) Project Time Management:
Managing everything that affects the projects schedule.
Building the product at right time for maximum customer acceptance.


(3) Project Cost Management:
Cost estimating, budgeting, and controlling the costs involved in building and maintaining the project.


(4) Project Quality Management:
Ensuring that the product we are producing is a quality product and that it meets customer expectations.


(5) Project Human Resources Management:
Hiring and managing the competent people to work for the project.


(6) Project Communications Management:
Making sure that the people who information need get it, when they need it.


(7) Project Risk Management:
Anticipating and handling risks as well as taking advantage of opportunities that can help a project.


(8) Project Procurement Management:
Creating vendor contracts and purchasing goods and services.


(9) Project integration Management:
• Ensuring perfect coordination between all the knowledge areas.


To Download : http://www.megaupload.com/?d=TRJ8N7QE

Project Dimensions

Project dimensions include People, Product, Process, and Technology
(1) People: People management includes Recruiting, Selection, Performance management, Training, Compensation, Career development, Work design, Team culture and Development

(2) Product: Before a project can be planned product objectives and scope should be established. Alternative solutions should be considered. Technical and management constraints should be identified. The software developer and customer must meet to define product objectives and scope. Scope identifies the primary data, functions and behaviors that characterize the product. Once the product objectives and scope are understood alternative solutions are considered.

(3) Process: A software process provides the framework from which a comprehensive plan for software development can be established. A number of different activities like tasks, milestones, work products and quality assurance points – enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally umbrella activities such as software quality assurance, software configuration management, and measurement are carried out during the process follow up.

(4) Technology: Analysis of presently available technology to implement the project. Assessing the risks associated with the implementation of the technology especially while implementing new technology. Adopting technology that would reduce the cost of the finally built product. Imparting training about using the technology for team members who are new to the technology. Upgrading the implemented technology from time to time.

Procurement Management

Procurement management processes includes:
(a) Procurement Planning (b) Solicitation Planning (c) Solicitation (d) Source Selection (e) Contract Administration (f) Contract Close-out


(a) Procurement Planning: This involves taking decision on
                                                 • What to procure?
                                                 • What type of contract to use?
                                                 • Financial and organizations issues

(b) Solicitation Planning: Make or buy analysis is used for determining the cost effectiveness of procurement. PMs need to consult experts to assist them with the legal aspects of contracts. Decisions need to be made about appropriateness of the types of contracts e.g. fixed price contracts (more risk to seller), Cost reimbursable contracts (more risk to buyer), Unit price contracts (fixed price to seller and risks passed on to buyer). Solicitation planning includes:
• Writing the statement of work in sufficient details.
• Preparing procurement documents e.g. Request for proposal (RFP), Request for bid (RFB), Request for information (RFI).
• Developing source selection evaluation criteria.

(c) Solicitation: This involves:-
 • Finalizing procurement documents
• Advertising the work
• Providing clarifications
• Holding bidder’s conference
• Receiving proposal

(d) Source Selection: Source selection criteria cover:-
• Technical criteria
• Management criteria should also be given due importance

(e) Contract Administration: This involves:
• Finalizing and awarding the contract
• Monitoring performance
• Making contract modification (when required)
• Project members should be involved in writing and administering the contracts

(f) Contract Close-out: This include product verification and administrative close out e.g. formal acceptance, closure, contract file archiving.


To Download : http://www.megaupload.com/?d=VNDQJGO1

CE Charts

The main purpose of the CE diagram is to graphically represent the relationship between an effect and its various possible causes. The main steps in drawing a cause-effect diagram are as follows:-
(1) Clearly define the problem (the effect) to be studied. Here we can find the problems of particular types that are occurring in the system.
(2) We draw an arrow from left to right with a box containing the effect drawn at the head. This is the backbone of the diagram.
(3) We determine the major categories of causes. These could be the standard categories or some variation to suit the problem.
(4) We then write these major categories in boxes and connect them with diagonal arrows to the backbone.
(5) Then Brainstorm for the sub-causes of the major causes by asking repeatedly for each major cause “Why does this major cause produce the effect”?
(6) Then we add the sub-causes to the diagram clustered around the major cause. If necessary further we subdivided these causes & stop when no worthwhile answer to the question can be found.

   

Statement of Work (SOW)

Sow describes all work products that will be produced and a list of people who will perform that work. It has a detailed description of all of the work products that will be created over the course of the project. A list of features that will be developed. A description of each intermediate deliverable or work product that will be built. 

COCOMO MODEL

The constructive Cost model (COCOMO) is an empirical estimation model i.e. the model uses a theoretically derived formula to predict cost related factors. This model was created by “Barry Boehm”. The COCOMO model consists of three models:-
(1) The Basic COCOMO Model: It computes the effort & related cost applied on the software development process as a function of program size expressed in terms of estimated lines of code (LOC or KLOC).
(2) The Intermediate COCOMO Model: It computes the software development effort as a function of – Program size and A set of cost drivers that include subjective assessments of product, hardware, personnel, and project attributes.
(3) The Advanced COCOMO Model: It incorporates all the characteristic of the intermediate version along with an assessment of cost driver’s impact on each step of software engineering process.

The COCOMO Model is defined for three classes of software projects stated as follows:-
(1) Organic Projects: These are relatively small and simple software projects which require small team structure having good application experiences.
(2) Semi-detached projects: These are medium size projects with a mix of rigid and less than rigid requirements level.
(3) Embedded Projects: These are large projects that have a very rigid requirement level. Here the 
hardware, software and operational constraints are of prime importance.

In below we will discuss only the Basic & intermediate COCOMO Models: