Project Integration Management

In an enterprise solution project, a large number of activities must be performed, and the project must be viewed from several perspectives. For examples, ideally, project may  have difference phases like Project initiating, Planning, Executing, Monitoring and Controlling and  project Closing. Project Manager has responsibility of delivering the product that must meet clients needs and expectations on time, within budget. Project Manager has daunting task of monitoring, tracking and controlling all the activities of the project start with Project Initiation, Planning, Executing and Monitoring and end with Product delivery and closing.

 

As PMBOK states, in order to assist Project Manager to keep a watch and monitor  and control all the activities of the project, Project Integration Management Knowledge Area is needed to identify, define, combine, unify and coordinate the various processes ad project management activities. Basically, PIMKA includes the processes and activities that help the Project Manger to keep a watch on all the activities of the project and manage, monitor, control the project better. Integration help the project manager to coordinate betweens different processes of the Project Process Groups. Integration, in the context of managing a project, is making choices about where to concentrate resources and effort on any given day, anticipating potential issues, dealing with other issues before they become critical and coordinating work for the overall project good. For example, many processes are iterative and Project Manager need to revisit them in the project for different activities. For example, Project Manage develop Project Management Plan in planning process, but later while executing the project if some change requests occur then he needs to update the project management plan.  If Project Manager understands integrative nature of project and project management, then its job becomes easier and he can manage processes, resources better for the project. For example,

 

The Integrative Project Management processes include:

 

1.    Project Charter

 

No project can start without project Charter. Project is a document that formally authorizes the project. The Project charter provides the project manager with the authority to apply organizational resources to project activities. Usually, A project initiator or sponsor capable of funding the project issues the Project charter.

 

Project can be charted as a result of market demand, business needs, customer requests, technological advances, a legal requirements, social needs. Developing the project charter is primarily concerned with documenting the business needs, project product, service, or result that is intended to satisfy those requirements.

 

The Project Charter should include the requirements that satisfy customer, sponsor, and other stakeholder needs, wants and expectations. It should also address Project s purpose, stakeholder ‘s influence, assumptions , constraints, summary budget etc.

 

Developing Project Charter:

 

 

There are 4 factors which could have substantial impact on the development of Project charter which are as follows:

 

1.    Contract

          A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.

 

2.                Project Statement of Work

The SOW is a narrative description of products or services  to be supplied by the project. For internal projects, Project Initiator or sponsor provides the SOW based on business needs, product, or service requirement. For external projects, SOW can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. SOW may include, business need, Product scope description, strategic planning.

 

3.                Enterprise Environmental Factors ( EEF)

When developing the project charter, any and all of the organization ‘s enterprise environmental factors and systems that surround and influence the project ‘s success must be considered. EEF may include items like Organization culture and structure, Infrastructure, Human Resource, PMIS, Personal Administration, Industry standards etc.

 

4.                Organizational Process Assets ( OPA)

When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project ‘s success can be drawn from organization process assets. Organizational process assets can be organized differently, depending on the type of industry, organization, and application area. For example, the organizational process assets could be grouped into 2 categories i.e.

Organization ‘s process and procedures for conducting work for example Organization policies, standards, Standardized guidelines, Templates, project close guidelines,  change and risk control procedure etc. and

Organizational corporate knowledge base for storing and retrieving information for example, project files, historical information, configuration and change management knowledge base, Issue and defect management database contain issue and defect status, change control, issue and defect resolution and action items results. Process measurement database used to collect and make available measurement data on processes and products. documentation from previous project.

 

Tool and Technique:

 

Project Selection Methods : Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories  Benefit measurement methods that are comparative approaches, scoring models, benefit contributions or economic models Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.

 

Project Management Methodology, Project Management Information System and Expert Judgment these tools are used in almost all the processes of Project Integration Management to develop required out for that particular processes. For example, PMM, PMIS and expert judgment can help Project management to prepare Preliminary Project scope statement.

 

·         Project Management Methodology (PMM)

 

A Project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. It can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.

 

·         Project Management Information System (PMIS )

The PMIS is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is defined, control changes to the project charter and release the approval document.

 

·         Expert Judgment

Expert judgment is often used to assess the input needed to develop the project charter. Such judgment and expertise is applied to any technical and management detail during this process.

 

Developing Preliminary Project Scope Statement

 

Once Project charter is developed and issued and Project manager for the project has been identified, then defining the project scope statement is the task that needs to be accomplished. The preliminary Project Scope Statement specifies that what should be the goals and objectives of the project and what needs to be accomplished for the project.

 

A project scope statement includes Project and product objectives, Product Acceptance Criteria, Project boundaries, assumptions and constraints, project requirements and deliverables, initial defined risk, schedule milestone, WBS, Summary of budget, Configuration management etc

 

The preliminary project scope statement is developed from information provided by the initiator or sponsor. For developing preliminary project scope statement, project charter, Project statement of work, Enterprise Environmental Factor, Organizational Process Assets are used as input. PMM processes help the project management team in developing and controlling changes to the preliminary project scope statement. The PMIS, an automated system, is used by the project management team to support generation of a preliminary project scope statement, facilitate feedback, as the document is refined, control changes to the project scope statement, and release the approved document. Expert judgment is applied to any technical and management details to be included in the preliminary project scope statement.

 

Developing Project Management Plan

The Project management plan defines how the project is executed, monitored and controlled and closed.  The Develop project management plan process includes the actions necessary to define, integrate, and coordinate all subsidiary plans into a project management plan. : For example,  Project Scope, Schedule, Cost , Quality, Process, Staffing, Communication, Risk, Procurement Management Plan.

 

The Project Management Plan content will vary depending upon the application area and complexity of the project.   The Project Management Plan documents the collections of outputs of the planning processes of the planning Process Group. During PMP, Project Management team select Project Management process which needs to be executed throughout the life cycle of the project,  tool and technique to be used for accomplishing those process, how change and configuration control management will be monitored and controlled and how work will be executed to accomplish the objective of the project.

 

It may have components but not limited to: Milestone list,  Resource Calendar,  Schedule Baseline,  Cost baseline,        Quality baseline, Risk register etc

 

For developing Project Management Plan, Preliminary Project scope statement, project management process, EEF, OPA can be input. Tool and technique could be PMM and PMIS including Project configuration management and Change control system and Expert judgment.

 

Direct and Manage Project Execution

The Direct and Manage project execution process requires the project manager and the project team to perform multiple actions to execute the project management plan to accomplish the work defined in the project scope statement. Some of those actions are:

 

·         Perform activities to accomplish project activities

·         Expend effort and spend funds to accomplish the project objectives

·         Staff, train, and manage the project team members assigned to the project

·         Obtain quotations, bids, offers, or proposals as appropriate

·         Select sellers by choosing from among potential sellers

·         Obtain, manage, and use resources including materials, tools, equipment and facilities

·         Implement the planned methods and standards

·         Create, control, verify, and validate project deliverables

·         Manage risks and implement risk response activities

·         Manage Sellers

·         Adapt approved changes into the project ‘s scope, plans and environment

·         Establish and manage project communication channels, both external and internal to the project.

·         Collect project data and report cost, schedule, technical and quality progress, and status information to facilitate forecasting

·         Collect and document lessons learned, and implement approved process improvement activities

 

Deliverables are produced as outputs from the processes performed to accomplish the project work planned and scheduled in the project management plan. Work performance information about the completion status of the deliverables, and what has been accomplished, is collected as part of project execution and is fed into the performance reporting process.

 

Input for the Direct and Manage Project execution are , Project Management Plan, Approved Corrective Actions, Approved corrective actions are documented, authorized directions required to bring expected future project performance into conformance with the project management plan. Approved Preventive Actions, Approved preventive actions are documented, authorized directions that reduce the probability of negative consequences associated with project risks, Approved Change Requests, Approved change request are the documented, authorized changes to expand or contract project scope. The approved changes requests can also modify policies, project management plans, procedures, costs or budgets, or revise schedules. Approved change request are schedules for implementation by the project team.

Approved Defect Repair: The approved defect repair is the documented, authorized request for product correction of a defect found during the quality inspection or the audit process.

Validates Defect Repair: Notification that re inspected repaired items have either been accepted or rejected.

     Administrative Closure Procedure

The administrative closure procedure documents all the activities,  interactions, and related roles and responsibilities needed in executing the administrative closure procedure for the project.

 

Deliverables

A deliverables is any unique and verifiable product, result or capability to perform a service that is identified in the Project Management Plan documentation and must be produced and provided to complete the project.

 

Requested Changes

Change requested to expand or reduce project scope, to modify policies or procedures, to modify project cost or budget, or to revise the project schedule are often identified while project work is being performed. Request for a change can be direct or indirect, externally or internally initiated, and can be optional or legally/contractually mandated.

 

Implemented Change Requests

Approved change requests that have been implemented by the project management team during project execution.

 

Implemented Corrective Actions:

The approved corrective actions that have been implemented by the project management team to bring expected future project performance into conformance with the project management plan.

 

Implemented Preventive Actions

The Approved preventive actions that have been implemented by the project management team to reduce the consequences of project risks.

 

Implemented Defect Repair

During project execution, the project management team has implemented approved product defect corrections.

 

Work Performance Information

Information on the status of the project activities being performed to accomplish the project work is routinely collected as part of the project management plan execution. This information includes, but is not limited to:

·                                 Schedule progress showing status information

·                                 Deliverables that have been completed and those not completed

·                                 Schedule activities that have started and those that have been finished

·                                 Extent to which quality standards are being met

·                                 Cost authorized and incurred

·                                 Estimates to complete the schedule activities that have started

·                                 Percent physically complete of the in progress schedule activities

·                                 Documented lesson learned posted to the lessons learned knowledge base

·                                 Resource utilization details

 

 

Monitor and Control Project Work

 

This process is performed to monitor project process associated with initiating, planning, executing and closing. Corrective or preventive actions are taken to control the project performance. Monitoring includes collecting, measuring, and disseminating performance information and assessing measurement and trends to effects process improvements.

 

The Monitor and Control Project Work Process is concerned with:

·            Comparing actual project performance against the project management plan

·            Assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary

·             Analyzing, tracking, and monitoring project risks to make sure the risks are identified, their status is reported, and that appropriate risk response plans are being executed

·             Maintaining an accurate, timely information base concerning the project’s products(s) and their associated documentation through project completion.

·              Providing information to support status reporting, progress measurement and forecasting

·             Providing forecast to update current cost and current schedule information

·              Monitoring implementation of approved changes when and as they occur

 

 

Project Management Plan, Work Performance Information, Rejected Change Request are used as input for Monitor and Control Project Work.

As for Tools and technique is concerned, PMM, PMIS, Expert judgment and

Earned value technique.

 

The earned value technique measure performance of the project as it moves from project initiationt through project closure. The earned value management methodology also provides a means to forecast future performance based upon past performance.

Recommended Corrective Action

Corrective actions are document recommendations required to bring expected future project performance into conformance with the project management plan.

 

Recommended Preventive Actions

Corrective actions are document recommendations that reduce the probability of negative consequence associated with the project risks.

 

Forecast

It includes estimates or predictions of conditions and events in the project ‘s future, based on information and knowledge available at the time of the forecast.

 

Recommended Defect Repair

Some defects which are found during the quality inspection and audit process, are recommended for correction.

 

Requested Changes:

 

Integrated Change Control:

 

The Integrated Change Control Process is performed from project inception through completion. Change control is necessary because project seldom run exactly according to the project management plan. The project management plan, the project scope statement, and other  deliverables must be maintained by carefully and continuously managing changes, either by rejecting changes or by approving changes so those approved changes are incorporated into a revised baseline.

 

Proposed changes can require new or revised cost estimates, schedule activity sequences, schedule dates, resource requirements, and analysis of risk response alternative.

 

Some of the configuration management activities included in the integrated change control process are:

 

Configuration Identification:

Providing the basis from which the configuration of products is defined and verified, products and documents are labeled, changes are managed, and accountability is maintained.

 

Configuration Status Accounting

Capturing, storing, and accessing configuration information  needed to manage products and product information effectively.

 

Configuration Verification and Auditing

Establishing that the performance and functional requirements defined in the configuration defined in the configuration documentation have been met.

Every documented requested change must be either accepted or rejected by some authority within the project management team or an external organization representing the initiator, sponsor, or customer.

 

Close projects

 

The Close Project process involves performing the project closure portion of the project management plan.  Two procedures are developed to establish the interactions necessary to perform the closure activities across the entire project or for project phase:

 

Administrative closure procedure:

 

This procedure details all the activities interactions and related roles and responsibilities of the project team member and other stakeholders involved in executing the administrative closure procedure for the project. Performing the administrative closure also include integrated activities needed to collect project records, analyze project success or failure, gather lesson learned, and archive project information for future use by the organization.

 

Contract closure procedure:

Include all activities and interactions needed to settled and close any contract agreement established for the project, as well as define those related activities supporting the formal administrative closure of the project.

 

References:  PMBOK 3^rd Edition

 

Project Scope Management

It is not unusual to see the project team working on their toe to meet the unrealistic deadline due to callously defined scope. I had worked on such laborious and frantic project as a team member. However, I learned the important lesson that is scope of the project must be planned, clearly defined, agreed by the all the stakeholders and have some mechanism and plan for controlling change in scope throughout the life cycle of the project. The scope of a project specifies what the solution will and will not do. The features that the customer considers mandatory in the solution define the scope.

 

Many project get delayed or scrapped due to vague and incomplete project scope. Due to ambiguous, incomplete and transient scope nature, sometimes team have no clue as what needs to be included in the final release or what should be left out as client keep on changing the requirements. If Project has no collaborative scope control planning, then frequent change in requirement also put drastic impact on the cost and schedule of the project. It may also lead to conflict with client over the requirements included in the project and future business with the client could also be affected.

 

I guess you got a fair amount of idea why project scope management is an essential.  Now you must be thinking how to perform project scope management and how it will help us to resolve the issues, which could arise due to uncollaborative and ambiguous scope. There is no rocket science needed to perform Project scope management. As PMBOK precisely states, Project Scope Management includes the processes required to ensure that the project includes all the work required and only the work required, to complete the project successfully. It takes care of the customer needs, wants and requirements. It is primarily concerned with defining and controlling what is and is not included in the project. It ensures that project will be delivering what has been asked and approved by stakeholders/sponsors, no more, no less.

 

Project Scope management includes following processes:

 

Scope Planning:

 

Project Scope management is the heart of Project Management plan. It can be the defined in the of Project Management plan. Project Management define the scope management plan that documents how the project scope will be defined, verified, controlled, and how the work breakdown structure (WBS) will be created and defined.

 

The project scope management plan can be informal and broadly framed or formal and highly detailed, based on the needs of the project.  There are many factors that can have a impact on Project scope management e.g. Enterprise environmental and Organizational Process. For example Organization may have different policies, procedures, tools, infrastructure, human resources that could affect how project scope is managed. Organizational factor like processes, formal and informal policies, guidelines that could also impact how project scope is planned.

So every organization have different way to do project scope planning but their goal and objective of having project scope planning is common.

 

Project Scope Management needs Tools and Techniques like Expert Judgment, template, Forms and standards to perform Project Scope Planning. Expert Judgment help in developing Project Scope Planning by utilizing their experience and skills with similar kind of the project in the past. Template could include work break down structure templates, scope management plan templates, project scope change control forms.

 

Project Scope Management planning should include following processes:

 

• A process that will have detailed project scope statement based upon preliminary project scope statement and requirement gathering and analyzing.
• A process that enables the creation of the Work Break Structure from the detailed project scope statement, and established how the WBS will be maintained and approved.
• A process that specified how formal verification and acceptance of the completed project deliverables will be obtained.
• A process to control how request for changes to the detailed project scope statement will be processed. This process is directly linked to the integrated change control process.

 

 

Scope Definition:

 

Scope definition is primarily concerned with what is and is not included in the project. It involves taking the preliminary project scope statement created during the initiating process group and fleshing it out to include all the needs of the stakeholders. Scope Definitions take into account constraints and assumptions. The result, or output, is the project scope statement which is used to manage and measure project performance against.

 

Detailed Project Scope statement is builds upon the major deliverables, assumptions, and constraints that are documented during project initiation in the preliminary project scope statement. While defining the scope of the project, you identify the requirements that will be addressed by the various versions of the solution.

 

Project Scope statement also provide the common understanding of the project scope among all project stakeholders and describes the project ‘s major objectives. It also enables the project team to perform more detailed planning, guides the project team ‘s work during execution, and provides the baseline for evaluating whether requests for changes  or additional work are contained within or outside the project boundaries.

 

The detailed project scope statement includes:

 

• Project Objective:

Project objective include the measurable success criteria of the project. Project objectives can also include cost, schedule, and quality targets. Project may have a wide variety of business, cost, schedule, technical and quality objective.

 

• StakeHolder Analysis

This process makes sure that the stake holder’s needs, wants and expectations are turned into requirements.

 

• Product Analysis

The purpose of the product analysis is to analyze the objective stated by the customer or sponsor and turn them into tangible requirements. For example, the project team is asked to “improve” the product. In product analysis, the project team might come up with specific requirements that meets the need to “improve” the product.

 

• Product scope description:

It should describe the characteristics of the product, service, or result that the project was undertaken to create. While the form and substance of the characteristics will vary, the scope description should always provide sufficient details to support later project scope planning.

 

• Project requirements:

It describe the conditions or capabilities that must be met or possessed by the deliverables of the project to satisfy a contract, standard, specification or other formally imposed documents. All of Stakeholder ‘s needs, wants, and expectations are translated into prioritized requirements.

 

• Project boundaries:

Identifies, generally what is included within the project. It should also states explicitly what is excluded from the project, if a stakeholder might assume that a particular product, service, or result could be a component of the project.

 

 

• Project deliverables

Project Deliverables that comprises the product or services of the project  as well as ancillary results such as project management reports and documentation. It should define the process and criteria for accepting completed product.

 

• Constraints:

It lists and describe the specific project constraints associated with the project scope. For example, a predefined budget or any imposed dates ( schedule milestones ) that are issued by the customer or performing organization are included.

 

• Assumptions:

 It should also define a list of expected assumptions with the project scope and the potential impact of those assumptions if they prove to be false.   Assumption can be Fund limitation, Project specification, Cost estimate, schedule milestone, initial defined risks, approval requirement etc. It describes the process to manage the requested changes to the project management plan and its subsidiary plans may be developed during the Scope Definition process.

 

Creating  Work Break Structure:

 

The Work Break structure all you to subdivide the major projects into more manageable components and organizes and defines the total scope of the project. The WBS contains the deliverables-oriented hierarchical decomposition of the work executed by the team to accomplish the goal and objective of the project.  It does not include the day-to-day activities or tasks assigned for the team because activities and tasks tend to be flexible and keep on changing. The WBS represents the work specified in the current approved project scope statement and assists the stakeholders in viewing the deliverables of the project. The planned work contained within the lowest level WBS components, which are called work packages, can be scheduled, cost, estimated, monitored and controlled.

 

In the WBS, following rules are followed:

 

• It is created with the help of the team.
• The first level is completed before the project is broken down further.
• Each level of the WBS is a smaller piece of the level above.
• The entire project is included in each of the highest levels of the WBS. Eventually some levels will be broken down further than others.
• Includes only work needed to create deliverables.
• Work not in the WBS is not part of the project.
• Continues breaking down the project until you reach what are called work packages pieces that:
  • Can be realistically and confidently estimated
  • Can not be logically subdivided further
  • Can be completed quickly
  • Having a meaningful conclusion and deliverable
  • Can be completed without interruption ( without the need for more information)

The benefits of the using a WBS are:

• Helps to prevent work from slipping through the cracks
• Provides the project team with an understanding of where their pieces fit into the overall project management plan and gives them an indication of the impact of their work on the project as a whole.

Scope Verification:

 

Scope verification is actually checking the work against the project management plan and the project scope management plan, WBS, WBS dictionary, and then meeting with the customer to gain formal acceptance of deliverables. Scope verification is the process of obtaining the stake holder’s formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. If the project is terminated early,  the project scope verification process should establish and document the level and extent of completion. Scope verification differs from quality control in that scope verification is primarily concerned with the acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables. Quality control is generally performed before scope verification, but these two processes can be performed in parallel.

 

Scope Control:

 

Project scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process. Project Scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process. To control a project, one  needs to focus on controlling scope as well as looking for the impact of scope changes on other knowledge areas and the impact of other changes on scope (integrated change control). Remember that scope control is extremely proactive.

 

Scope control involves following the change control process set up in the project scope management plan. To control scope, one first needs to have a clear definition of what is the scope of the project; the project scope statement, WBS and WBS dictionary. One then has to measure scope performance against the scope baseline. Once that information is known, the next step is to determine if any updates to the project management plan or the components of the scope baseline are needed, and what corrective and preventive actions should be recommended.

 

Project scope change  control system, documented in the project scope management plan, defines the procedures by which the project scope and product scope can be changed. The system includes the documentation, tracking system and approval levels necessary for authorizing changes. The scope change control system is integrated with any overall project management information system to control project scope. When the project is managed under a contract, the change control system also complies with relevant contractual provision.

If the approved change requests have an effect upon the project scope, then the project scope statement is revised and reissued to reflect the approved changes. The updated project scope statement becomes the new project scope baseline for future changes. If the approved change requests have an effect upon the project scope, then the WBS is revised and reissued to reflect the approved changes. If the approved change requests have an effect upon the project scope, then the WBS dictionary is revised and reissued to reflect the approved changes.

Many comprehensive articles on Project  Management including scope management has also been published  on www.pmhut.com.

If you want to learn Project scope management more in details, you may like to look at http://www.pmhut.com/category/change-management/ as well.

References :

•   Project Management Body of Knowledge (PMBOK) 3rd Edition
•   Rita Mulchay ’s PMP Exam Preparation 2005 5th Edition
•   Analyzing requirements and defining Microsoft .Net solutions architecture

 

How to become Proactive Project Manager?

To deliver a solution on schedule, on budget  and within project constraints, strong Project Management skills are essential. Project management is a process that combines a set of knowledge, skills and techniques to address and plan the tasks and activities required to meet the objective and goal of the project. Proactive Project manager must have knowledge, skills and technique to plan the tasks, to meet the objective and goals of the project.  Proactive Project manager may not guarantee you that you won’t have risks, unexpected issues or change in requirements in project but he/she will have better processes and plan in place to deal with all this unpredictable, hostile and crunch situations.

Proactive Project Manager should have the  following skill sets:

Effective communication:

Project  Manager spent 90% of his time on project planning and designing plan, communicating, organizing stating meeting and mitigating risks and issues, updates, status reports and courteous and effective email. Project Manager provides vision and direction to the team. In order to help him perform all the said activities proactively, Project Manager must have good written and verbal communication skills. He also needs to have good presentation skills. Sometimes,  Project Manager needs to give presentation to the client/project stakeholder/project team . He should be good at keeping his point across clearly.

You can read article on effective communication on the following link:

http://www.drbalternatives.com/articles/cc2.html

Strong Organizers:

Project Manager should be good at generating and keeping track of all project related documents that help him/her keep track of overall activities of the project. proactiveProject Manager needs to be aware of all the processes, which help him/her to monitor the progress of the project and deal with unpredictable issues, and ensure that project is in good health.

You can read good article on Organizing on the following link:

http://www.worklifecoach.com/ten_easy_organizing.pdf

Leading from front attitude:

Project team always looks to Project Manager for guidance, direction and decision making. Project manager  should have great leadership skills and he/she should lead from the front. People always like to work under hard working boss and respect him/her. PM should be a good listener and should know how to get things done by not putting extra pressure on team. He should make working on the project an enjoyable experience rather than making it mere tedious and lackluster job. He needs to have cool head for handling the things at crunch situation because If project manager get panic during hostile situation, it will have drastic impact on the morale of the team.

You can see more qualities of leadership at the following link:

http://www.girlscouts.org/for_adults/leader_magazine/2004_fall/five_qualities.asp

Problem Solving Skills:

Project Manager needs to have great problem solving abilities. He should have some knowledge of technology and should understand the domain and  business problem. Proactive Project Manager work on the problems and its solution and is not involved in finger pointing. This quality will help him to understand, assess and resolve project team ‘s issues and problem. He/She does  not wait for the problem to occur then fix it, he/she act proactively and foresee the problem well in advance and have plan in place to deal with them. He/She got to have a big picture of everything all the time.

You can read nice article on Problem Solving skills in details at the following link:

http://www.mindtools.com/pages/article/newTMC_00.htm

Team Motivation:

A project has many activities. We needs role with responsibilities to perform day to day activities of the project. Needless to say, all roles needs to perform and contribute as per their responsibilities in order to make a project a big success. For example, role could be team lead, group lead, developer. If some of the role does not contribute well, project may have dire consequences. It is the responsibility of the Project Manager to keep on motivating his team. PM should give reward for team ‘s achievement. For example, PM may take team out for lunch/dinner. Believe me, it helps. Good PM should also provide honest feedback and give a challenges to the team. PM should make each team member feel  they are very important for the project and  adding value to the project and the organization.

You can read nice article on team building and motivation at the following link:

http://www.teambuildinginc.com/article_teammotivation.htm

Project Configuration Management

In the project envisioning and planning phase, we gather requirements and analyze them. Then Create a problem statement and  make a Vision/Scope statement. Once vision/scope statement is approved by the clients, we identify all the items deliverable in the project with their timeline. We also take client ‘s approval for each and every deliverable. In the project, there are also issue of wrong code or old document has been delivered to the client. Sometime it happens programmer lose its code due to project pressure. Sometimes you lose the code because virus infected to development machine. Also, sometimes clients wants old functionality back, in case you don’t track of old code or old documents, you have to do a lot of reworks. In order to overcome this problem, we needs to have Project Configuration plan in place for the project.

 

All the deliverable items i.e. code or document etc, should be identified as controlled or configurable items and need to plan how you are going to configure them. You may also identify other items as controlled items which are very important in day to day activities of the project. You may need to use special application to manage the controlled items like VSS for managing code and SharePoint or Lotus notes or File folder structure for managing documents.

 

Configuration Manager :

 

We need special role called Configuration Manager to perform configuring, managing and tracking all the controlled or deliverables items for the project. Like DPR, senior team member needs to be assigned CM role. Team should be trained on all the configuration activities for the project. CM also share his past experience with the project team to manage the controlled items efficiently. CM reports to Project leader for all the Configuration activities he does for the project. Project management also needs to decide how often they require project configuration activity for the project. CM also take care of other configuration issue like setup development  and test environment and making build. He also helped the team for solving their code version and tracking problem

 

 Traceability Matrix:

Sometimes it may so happen in the project that your deliverable miss few requirements or needs of the clients. Requirements were there in BRD but somehow it was overlooked because of hectic project schedule. Now to prevent this kind of problem in project. Traceability Matrix is best answer to this kind of the problem. Traceability Matrix is a sheet which consists of a list of requirements and their corresponding solution with their code files. So if you are missing some requirements, you can come to know immediately by looking at the Traceability Matrix. It helps you trace requirements in all the phases of project life cycles. For example, you have some requirements for add upload functionality in some page, and then Traceability Matrix will show you which section of functional specification you have updated for it. Which code files you have modified etc.

 

Back up and Recovery:

CM needs to perform these activities. Project needs to plan back up and recovery procedure as per project requirements. Ideally, backup and recovery procedure should be done on weekly basis. Every week, cm take the back up of all the controlled items on tapes and the verify the backup by doing recovery testing for it.

 

Release Product Checklist:

Delivery date or production push date is always tough and hectic for the project team. You have no idea what going to happen in the production, your code may have some issue in production. Sometime, we forget to provide important installation guideline to the deployment time. Sometime we push old version of the code in the production. Best solution is to have a release plan checklist. So before delivering any  deliverable, we need to fill that checklist like all the versions of the code needs to be checked, documents also needs to be checked and verified. Also verify push instruction file if required for the project. CM also fill Release Product checklist and ensure that correct versions of codes, documents and others items delivered to the clients.

 

You may like to see more detail about Project Configuration Management at the follow link:

http://www.baz.com/kjordan/swse625/htm/tp-jm.htm

 

Defect Prevention Technique

I reiterate that  “Prevention is better than cure” This statement is hold true for Software development as well. Cost of preventing the defects is always lesser than reworking on the defects. DPP (Defect Prevention Plan) also lead us to achieve our goal of meeting the objective of Quality for the project. Project should have some processes in place to identify and fix the defects in the early stages of the project as I have already discussed in my post on Project Quality Management.

 

Defect Prevention Representative (DPR):

 

Project Management should  define, plan and discuss the goal of Defects Prevention technique  with team members. A role of Defect Prevention Representative (DPR)  play a major rule in Defect Prevention Activities. A senior team member should be assigned DPR role. DPR has responsibilities of sharing coding standards, guidelines, defects and best coding practices with the project team. DPR collect all the defects, analyze and make a report on causes and prevention of the defects. Ideally, he should make some histogram like Depareto Chart and give presentation to the team on the analysis of the defects and how team can prevent these defects in the future.

 

Coding Standards and Guidelines:

 

Project Management should identify and plan Coding standards, guideline for the project which Project team needs to follow throughout the project life cycle. Coding standards help the developer to keep the code simple, structured , easier to read and  modular. It also take less time to fix the defects in structured,  readable and modular code than unstructured and unreadable code.

 

Reviews :

 

Reviewing the code and other deliverables is the best way to nip the defects in the bud. Project Management should plan and discuss the type of reviews project team need to follow like Self Review, Peer Review and Peer to Peer reviews ( explained in PQM post).

 

Qualitative and Quantitative Analysis:

 

Nothing comes free. Defect Prevention technique is also cost us some resource time and efforts. It is very imperative to monitor the DP activities and their effectiveness. For example, if Project team find less defects in Review and more defects in QA testing. Then it indicates that our review strategies are not working but it is still costing  the project dearly. It could be laziness of resource issue or not enough time for review activity and action plan needs to be in place to tackle this issue. DPR role come into the picture here and he ensure that all the team members follow defect prevention activities religiously. Creating a Quality Metrics is a best way to do quantitative analysis for the DP activities. It helps us to determine that how effective DP activities are for the project. If DP activities are not effective, it means we are just wasting our time and efforts on this activities. Basically, quality metrics uses many formula to calculate effectiveness of review, cost of the Quality and cost of appraisal and failure cost.

 

Project Risk Management

 

Project risks are uncertain events or condition if occur, may have huge impact on cost, quality, time and scope. Project Risks could have low, medium or high impact. Project risks could have low, medium and high probability of occurrence.  If any risk associated with project has high probability and high impact. It means we need to be more vigilant for that kind of risk. For example, project requirements not frozen on schedule, it could lead to effort variance and schedule slippage for the project, Proper Infrastructure has to be setup for product deployment, it could be medium risk on the project. If you are not good at  Risk Management, you reputation as a Project Manager will be at stake. You may be in deep trouble if something happen unexpectedly and you were not prepared for it and you did not have any agreement with the client for the same.

 

As a proactive Project Manager you must ensure that all the risks associated with Project needs to be identified, plan, mitigates, execute, tracked and controlled. Don’t forget to involve stakeholder/sponsor/key player of the project in the Risk management process. You should made them aware of all the risks throughout the project and always update them time to time on the progress for risk mitigation by sending them risk tracking reports. You need to have mitigation plan in place to reduce the probability of occurrence of risks and impact on the project.

 

 

I can share my experience with you, I was working on web project. Initially the project was estimated and approved for 459 pds. When we started working on prototype, client kept on changing the requirements which result in effort variance to 610 pds. We have overworked 151 pds. Then our PM has spoken with client and asked him to approve change requirements for 151 pds. Initially he was reluctant to approve it, then my PM explained him what they have agreed it in Risk management plan. Thanks to PM , he had already identified  change in requirement as a risk and mitigation was change request procedure will follow and re-estimation of the new change request will be done. Then client approved the change request for 151 pds after looking at risk management plan.

 

If risks not identified, analyzed, mitigated and controlled efficiently, then loss could be anything from the diminished quality of a solution to increased cost, missed deadlines, or project failure. Project risks management is an iterative process and needs to be assessed continuously throughout a project.

 

You can have 3 strategies to deal with risk associated with project. These are as follows:

 

Avoid:

 

You can just avoid the risks by choosing familiar technology if you think new technology may cause high risk. You can also make some changes in project plan to avoid some risks like extending the project schedule and reducing the scope of the project

 

 

Transfer:  

 

Risk transfer requires a shifting a negative impact of threat along with ownership of the response, to third party. Contract may be used to transfer the specific risks to the third party. For example, you can say that if client does not approve the intermediate deliverable, project will be delayed and cost of the efforts will be re-estimated. This explain that your transferring responsibility of the risk on the shoulder of the client.

 

Mitigate:

Risk Mitigation implies a reduction in a probability and/or impact of adverse risk event to an acceptable threshold. For example, if your project has more complex functionality, you can plan for more testing time for it.

 

Risk Management includes following activities:

 

Risk Management Planning:

 

 

It is the process of deciding how to approach and conduct the risk management planning for the project. In this process, team manages current risks, plans and executes risks strategies. During the Risk Management planning, Project management also utilizes their experience for handling risks with previous projects. Some organization has well defined policies for handling risks management on the project. We also need to plan when and how often risk management process will be performed through the project.   We need to define tool, approaches and data source that may be used to perform Risk Management. Risk Management Planning should be completed early during Project Planning.

 

Risk Identification:

 

Risks needs to be identified and documented throughout the life cycle of the project. Project Management, Project Lead, Group leader, Stakeholder needs to be involved in the identification process of the risks.

People associated with risks also needs to be identified with their roles and responsibilities in risk management planning. 

 

Analyze and Prioritize risks

It is very essential to determine how often  risks may  occur on the project and how severe it will have impact on the project. All the risks may not necessarily have high probability of occurrence and high impact on the project. Calculating the risks help us to prioritize and mitigate the risks efficiently, for example risks having high probability and high impact on the project needs our extra attention. Ideally, we should  categorize probability of occurrence and impact of risk into low, medium and high. It is better to assign some numeric value to it. Like 1 to low, 2 to medium and 3 to high. Then you can draw the table depending on their probability of occurrence and impact on the project.

 

Risk Details	Probability High     = 3 Medium  = 2 Low      = 1 (A)	Impact/Damage High     = 3 Medium  = 2 Low      = 1             (B)	Total             (C) = (A) x (B)
Inexperience with Web site creation, deployment, and ongoing support	2	2	4
Proper infrastructure has to be setup on the Client deployment site before actual deployment.	2	2	4
Client changes requirement quite often.	2	3	6
Client slips on schedule for giving feedback on the intermediate deliverables.	2	3	6

 

Planning and Scheduling Risks Mitigation:

 

Once identification and analysis of the risks are done. Now we need to have some action plan in place to plan and schedule the risks. We have to use the information developed in the risk analysis stage to formulate risk mitigation strategies, plans, and actions. Allocate time for risk planning in the project plan.

 

All the risks must have mitigation plan identified with the person responsible for mitigation plan. PM needs to keep close watch on all the risks irrespective of their rating and ensure that mitigation plan is in place for all the risks. There are certain risks that you can avoid. For example, if new and unfamiliar technology is a risk for the project you can choose alternative technology for the project if it is feasible.

 

Tracking and Controlling:

 

We have to monitor the status of specific risks and the progress of their specific mitigation plans. We also need to report this progress to the team, customers, and key stakeholders. We need to execute the risk mitigation plan and report the status of the risks to the team and customer. I reiterate that Risk Management is an iterative process, risk needs to be identified, plan, mitigate, execute, tracked and controlled throughout the project.

 

Risks Also needs to be documents as a learning for future projects.

 

Sr. No	Risk Details	Occurrence Phase	Effect Details	Rating	Mitigation	Tracking	Contingency	Closed Date
2	Proper infrastructure has to be setup on the Client deployment site before actual deployment.	Deployment	This may cause a schedule overrun leading to extending the acceptance phase.	4	Client should ensure that it is properly done.	Deployment phase.	Escalate the issue to PM/Stakeholders/Sponsors at offshore. The client is already aware of the issue and has agreed to provide a proper setup.
4	Client changes requirement quite often.		This may cause a schedule overrun.	6	Proper Change Control Procedure will be followed.		Schedule changes into the application after acceptance of existing code.
5	Client slips on schedule for giving feedback on the intermediate deliverables.		This may cause a schedule overrun.	6	Client should ensure that feedback is given as per dates decided in the project plan.		Escalate the issue to PM/Stakeholders/Sponsors.

 

 Reference : Analyzing requierements  and Defining MS  .Net  Solution Architecture

 

 

 

Project Quality Management

 

Main objective of any software project is to deliver the product that meets or exceed the client ‘s expectation. Quality Management complements Project Management. Good Project management ensures that all the best quality tool and technique should be applied throughout the project. Many people tends to have perception that quality management is time consuming and tedious. It requires a lot of things needs to be documented, reviewed and monitored. Also, it is waste of time and increases the cost of the project. My experience says that if you don’t follow quality management for your project efficiently, you will have to deal with dire consequence of project delayed, over working on the project. Also Project  may suffers or scrapped if their quality is compromised or product does not meet customer ‘s need or expectation. I witnessed many projects where project team put a lot of extra efforts to meet the project deadline overlooking the quality of the project. It produces a negative consequence of rework, unfounded errors and attrition. So ignore Quality management at your peril.

 

Project Quality Management consists of processes which includes all the activities of performing organization that determine quality policies, objective and responsibilities so that project will satisfy the needs and requirements for which it was undertaken.

 

Project Quality Management include the following:

 

Quality Planning:

 

Identifying which standards, quality processes that can be relevant  to the project so that project will satisfy it needs.

 

Perform Quality Assurance:

Applying the planned, systematic quality activities to ensure that the project employ all processes needed to meet requirements.

 

Perform Quality Control:

Monitoring specific project results to determine whether they comply with relevant quality standard and identifying ways to eliminate the causes of unsatisfactory performance.

 

 Quality Planning: Tool and technique

 

It is always recommended that Quality planning should be discussed among the project team in the project kick off meeting. Project Management should guide the team regarding the objective and benefits of the quality management and Project team should be imparted the roadmap to achieve the objective of quality in the project with project team. Project team should be quality trained, motivated and guided enough to understand the objective of the quality as basic needs of the project, they should not take it for granted.

 

Objective of the quality for the project could be as follows:

• Deliver the product which meet or exceed the client ‘s expectation.
• Deliver the product on schedule.
• No critical bug should be found in Release product version.

Once objective of the quality for the project has been defined, next task is  to plan the roadmap to achieve objectives of the quality of the project.

 

Quality Planning should includes:

 

• Best practices learned:

It is always advisable to share the defects, preventive actions, best practices learned in the projects of similar nature. It will help the team to prevent the defects in the beginning itself.

 

• Rules, Standards and Guidelines:

 

There is a saying that Prevention is better than cure. Same logic apply here. The cost of preventing mistake is generally much less than the cost of correcting them. Rules, Standards and guideline helps us to prevent the defects in early stage of project life cycle.

For example, Coding Standards for C#, if programmer apply coding standards to his codes, you may prevent many defects which can be caused by inefficient programming like code not commented and indented, Code is not easily readable and not modular,  database connections are not closed in the end etc. So always remember, bug should be nipped in the bud as soon as possible.

 

Reviewing the code and documents reviews are best way to prevent defect in later stage of project life cycle. Reviews can be categorized into Self-Review, Peer review and Peer-to-Peer review:

 

·         Self-Review:

This is the software review process in which Programmer review his code and document and fix his defects in the excel worksheet. It is just to ensure that your code/document has complied with standards, rules and guideline as decided by project management for the project.

 

·         Peer to Peer review:

Peer to Peer review is the software review process in which your code or document reviewed against standards, guideline by your colleague who may be working on same project. He will share his finding with you and you have to fix it. You may review his code too if planned.

 

·         Peer reviews:

In Peer reviews, many of your colleagues review your code, one observe your code, one records your defects, one moderate the code. Then you have to fix the defect identified by the team. PM/PL decide whether they want to have Peer review for the project.

 

• Classification of defects:

Classification and analysis of defects is very essential for defect prevention. Ideally, defects should be identified into different categories like Critical defect, Functional defect, Cosmetic defects. All the defects should be reported in the excel sheet or special defect tracking tool.

 

• Assign And Scheduling Quality Assurance :

SQA ( Software Quality Analyst ) should be allocated to the project. He  play an important role in checking, verifying the day to day activities of the project and ensure that project is in good health

 

• Identifying Defect Prevention Representative (DPR)

 

             DPR does analysis for all the defects found in test cycles and come out with    some reports. Usually he draw some histogram and give presentation to the team for his analysis for all the defect. Idea behind this activity is defect prevention and learning.

 

 

Perform Quality Assurance:

 

A person who has task of performing Quality assurance for the project is called SQA ( Software Quality Assurance). He checks and verify all day to day activities and processes  of the project as per scheduled and  planned for the project. SQA ensure that project team is complied with the Quality related activities and process decided for the project. If he has some concerns for the project and he share it with project management and create some action plan to fix the issues.

 

Project team works on those action item. SQA verify the fixed action items and close it. He also give his suggestions/feedback if new processes is need for the project or project needs to deviate from the quality processes not relevant to the project. For example, some project may not require to do peer review at all because size of the project is small.

 

Perform Quality Control:

 

Performing quality control involves monitoring specifics project results to determine whether they comply with relevant quality standards and identifying ways to eliminate the causes of unsatisfactory results. It should be performed throughout the project.

 

The project management should have working knowledge of statistical quality control. A quality control department often performs quality control. Project team creates Project matrix which give the measurement of the processes followed in the project. Basically, metrics is based on the some formula, which can be vary project to project.

 

 For example formula to get % of review effectiveness= 100 * no of defect s found in review/ no of all defects found. Now suppose if you could find 8 defects in review and total number of defect are also 10. Then you will achieve 80% of review effectiveness, which is very good. Metrics also help you determine schedule variance, effort variance, cost of quality, and failure cost of the project.

 

 

 

 

 

 

Writing a proposal for Web Project

If you are working as Project Manager or Consultant or Senior Experienced Developer, It is quite common that you will be asked to write a proposal for new project. It is always challenging to bring a proposal to develop a new project for a client‘s Web Site. When competing for web design and development or marketing contracts, a professionally presented development proposal most often decides whether you lose or win the business. In the past, I have written many proposals that were reviewed and approved by the client. We also delivered the product on the basis of Proposal Approved successfully. I just wanted to share my proposal writing experience with you by writing this post. When putting together a basic web site proposal, you should include the following elements:

Executive Summary:
Describe the Business Problem statement and Vision/Scope statement here.
This element can have sub elements as follows:

• Objective:
  Describe Business Problem statement and Project. Vision/Scope statement.

• Timeframes & Price
  Describe the tentative start and end date of the project. Also, a list out the factors on which schedule
  and cost of the project will depends. For example, if team does not get feedback or approval from client within specific time,
  schedule and cost of the project may be affected.
  Also, describe why do you think your project team will be execute this project and deliver it on schedule and within budget successfully.
  Write some positive points of the company over its competitors.

Company Profile:
Describe company background or company history, business qualifications, technical skills, past achievements and contact details.

Scope of the Project:

The business you are submitting the proposal for, your understanding of their products and services, the target market, the goals of the web site and a rough outline of how you will achieve them.

This should also includes requirements which are excluded from the project and assumptions for the project.

Proposed Solution:

A description of style of site you are proposing. Elements from the client’s current branding you will utilize or new elements you will develop.

• Special Considerations:

such as globalization, security, performance or other issues pertaining to the business, site or target market that will need to be addressed.

Current Architecture:
A details description of the architecture of the current system and its shortcoming.

Proposed Architecture:

A details description of the architecture that will be used for the project. Also, describe how it will solve current business problem. It should be explained clearly with the help of Flow Chart or Visio Diagrams.

• Web site flow chart:

A diagram showing the different pages of the site and navigational structure.

• Flowchart Description:

A detailed description of each web page, how it fits in with the overall web site theme and the project element it addresses.

Proposed technology:

A details description of the technologies that will be used for the project like .Net framework, Web Services etc.
Also, Describe how the proposed technology will be most suitable for the project.

Development Timeline:

This should be a description of each stage of the web projects’ development, the estimated completion date of deliverables/milestones and notes regarding client consultation and supply of information/feedback from the client. Point should be clear made that schedule and cost of the project will be affected if there would be change in the requirements or delay in feedback or approval from Client side.

• Delivery Schedule

This should show the delivery date and mode of the delivery for all the deliverables/milestones for the project.

• Gantt Chart

The Gantt Chart for the project is shown below:
This should show the Gantt chart prepared for the project.

Project Management:

• Project Management

This should be summary of project management activities that will performed by
Project team. Project Key members like Business Deliver Owner and Project manager will be appointed. Project team will develop the project. It should be mentioned here that once proposal is approved then team can process with detail design of the project.
Also, it should indicate that client should give feedback/approve on time, failing to do so may delay the schedule and cost of the project.

• Project Plan Management

Here you can give details of the Project Management tools will be used for Project Management like MS Project, MS Excel, Project Monitoring System etc.
PMS provides the following features:

Project Management tool if available should provide :

• Project Setup

• Capturing Actual Effort

• Bug Tracking

• Quality Data Analysis

• Project Metrics Reports

• Employee Training Plans

• Weekly Status Report

Describe how Weekly Status report will be prepared and sent to the client..

• Monthly Project Status Review

This should explain how Monthly Project Status Review will help to monitor the progress of the project. It should also explain how the strategic issues like customer satisfaction, staff training, change control, risk management and deviations from company procedures will be reviewed.

• Project Quality Management

This gives detail description of Quality Processes and control to be followed in all phases of the project.

• Quality Objective

The detail description of Quality object explained here. like

• Deliver a product that meets and exceeds expectations.

• No schedule slippage.

• No P0 bugs are found during the Acceptance testing phase

• Formal technical review

Describe the details description of technical reviews plan for the project, like Code Review, checking for adherence to standards and naming convention.

• Software Testing

Describe the detail description of Software Unit Testing planning and Test Cases creation.

• Standards

Explain the standards and processes teal will follow throughout the life cycle of the project.

• Enforcement of Standard

Explain how team will follow standards in the Project Life Cycle.

• Bug Classification

Explain how bug will be classified for the project like P0 for Critical, P1 for Non Critical etc.

• Project Communication Management

Here you can give detail description of the communication that will be used for interacting with the client for his feedback and approval.

• Email

Here can you write details like email will be primary mode of communication and will be used for sending project documents to clients for his approval.

• Telephonic Conference

Here you can explain how telecon will be used to keep the project on track and in good health.

• Project Risk Management

This will have detail description of Project Risk Identification, and assessment and their mitigation plan.

• Project Related Risk

This should explain risks associated with the project like increasing or changing requirement from users, delay in client ‘s feedback/approval.

• Project Life Cycle

This should give detail description of the project life cycle model that will be used for the project with diagram. eg. Waterfall, agile, spiral, incremental etc

• Project Organizational Roles and Responsibilities

This should explain the roles and responsibilities of project team of clients and your organization.

• Team Structure

This should show the team structure of the project team in hierarchical fashion and also shows it will interact with client ‘s project team. Also, it should depict who reports whom.

• Project Configuration Management

This should explain the scope of the configuration activities for the project. This should explain how controlled items will stored and versioned.

• Configuration Items

You can give the list of all the items which have been identified as configuration items for the project like Functional specification, Detail Design, Source Code etc.

• Change Control Procedure

This will explain how team will handle change request for the project.
Template is given in the appendix.

• Reporting Procedures

This will explain the reporting procedure for the project. Like who will report whom and how the matter to be escalated in case of some conflict and problem.

Documentation :
Here you can give a list of documents will be prepared and delivered to the client for the project. Like function specification, detail design, user manual etc.

Project Costing:

A descriptive breakdown of costing phase wise or deliverable wise and total of quote including an end date before the price will need to be re-calculated.
No clients prefer to pay for project in advance or in full. So, describe that how much payment will be due after each phase or deliverable.

Ensure you take into account business related items including travel time, electricity, telephone and consumables.

Bear in mind that things rarely go strictly to plan in web design and delays can be expected.
Also, cost of the project dependent upon the complexity of the task and the competency of the designer.
In your eagerness to gain the contract, you may lose money if you quote too close to the bone. Time is money.

Acceptance:
This should give detailed description of the Acceptance guidelines and rules for the project.

• Acceptance Criteria

Describe the Acceptance criteria for the product to be delivered.

• Performance Guarantee

This should explain how the project team ensure that product have no performance issue.
Also, it will handle post production product related performance related issues.

• Acceptance Performance

Describe who will develop Acceptance test plan, also describe that it would be client ‘s responsibility to acknowledge, review and approve the delivery as complete and acceptable within 2 weeks of final delivery being made.
If rejected, team will rework the software to requirement.

Warranty Support:

Describe how long team will support the product after final release. Usually it is 30 after acceptance or deemed acceptance of the product. General Terms and conditions:

• Expectations and commitments

It is not unusual for web projects to be delayed due to clients not supplying feedback or content necessary to complete sections. It is just as important to be clear in what you expect from your clients as well as explaining your commitment to them. Conflict resolution issues and feedback mechanisms should be described.

Your clients will need to know what will occur if they do not supply information when requested, or request changes mid-stream and the action that you will take if you are running behind in the project yourself. You need to be clear on payment details and consequences of failure to pay for the services that you provide.

• Mock-ups (samples).

Be careful not to give too much away, just enough to give the client a good idea of what the site will look like. Ensure copyright notices and intellectual property statements are in place.

• Ongoing web site maintenance.

Summarize an offer of ongoing site maintenance or the implications of the client deciding to update or maintain the site themselves after it has been established.

Proposal Validity:

This should explain until when this proposal will be valid.

Disclosure:
You should make it clear that entire project will be performed by your company, if external resource is expected to become part of the team then it may be necessary to revisit costing based on effort redistribution.

Above points are usually sufficient to put together a professional web design proposal for a small to medium web based project. It had worked for us for many projects.
Be prepared to give presentation on the proposal to the client. Most of the clients prefer to have presentation on the proposal to ensure that they are reading from the same page. Also, first you need to release draft version of Proposal document and send it to Sponsor/Stakeholder so that if they want any changes, you can easily negotiate with them before releasing final version of the proposal. You should also ensure that Proposal should address all the concerns/issues client had laid down.
Also, many client like to negotiate with cost and schedule, so be prepared to do some heavy revisions to satisfy your client and find the middle ground where all parties feel comfortable.
Some clients wants Proposal documentation in certain format, respect that as well.

Also remember that some companies will ask you for proposals purely to use as a comparison against another designer that they are interested in utilizing; so try and limit the amount of time you spend on the draft until the client gives indication of serious interest.

Appendix A : Change Request Form
Customer Name :
Contact Name :
Project Id :
Project Manager/Leader(offshore) :
Project Name :
TO BE FILLED IN BY CLIENT :
Priority :
(Urgent, High, Medium, Low)
Initiated By :
Change Required :
Reasons :
Effort and Impact :.
Affected Modules & Documents :
Costing :
Decision : Approved / Not Approved : By : Date :

TO BE FILLED IN BY OWNER:
Request No :
Date Received By Offshore :
Effort and Impact :
Affected Modules & Documents :
Costing :

Estimating the Software Project

It is very essential activity of any project and success of any project depend on realistic estimation of the project. Most of the project suffer due to bad estimation. Estimation varies project to project and it depends on many factors. When it comes to estimating the project, team select experience person who has worked on similar project or technologies on which project based. There is no such thing as 100% correct estimation of the project exists, at least for me. My experience says that it is almost impossible to get accurate estimation of the project because there are many factors which we can not see or control  while estimating the project like requirement gathering,  technology issues, client feedbacks and approval, resource attrition, risk assessment.  

 Competition is another factor which lead to project team to estimate the project incorrectly because management put the pressure on team to give low estimate to  reduce the cost of the project in order to get the project from client. It put put huge pressure on the project team to complete the project within unrealistic and callous deadline. I have experienced working for such projects working day and night  like chicken with its headcut off. I am sure many people are still working offshore  for such projects minimum 12 hours a day. No, I am not saying that there is no rule or guidelines are available to get good estimation of the project. As I  said earlier, some rules and guidelines can be applicable to one project but same may not applicable to another project. For example, you can not apply same rules for estimating two different project like Asp based project and .Net Project/J2EE Project.So here are some rules and guidelines which I have experienced working for some projects. If the requirement gathering is done for the project or you have a fair idea what you need to develop for the client, then your next task is to estimate the project and send the proposal to the client, get his approval, if  project proposal is approved, then you can start working on next phases of project like planning, designing, coding and testing and deploying of the project.

 I am taking example of ASP based project for estimation. In the scenerio, you need to do first Screen based estimation. You need to identify all the screen. Classify the screen(GUI) in simple,  medium and complex. Depending on the functionality of the screen, for example you can estimate that simple screen will take like 2 pd (Person Day) and medium take 4 pd and complex take 6. So suppose if you have 15 medium screen, 8 medium and 5 complex. So total screens will be 28 and estimate for all the screens will 15 * 2 + 8 * 4 + 5 * 6 = 91 pd. So effort for completing 28 screens will be 91 pd. Same way you can do estimation for all the reports. Now next task is  to get FP (Function Points) based estimation. For example, in the Library Management System, Registering new memeber in LMS may be one function point. Now you have to estimate how many effort it will take to complete 1 FP. you have to divide the effort into all the phases of SDLC. for example, if you think Registering new member will take 20 PD, then you have to estimate that how much efforts you will be needing for Designing, Writing, Test Cases,Coding, Testing, Project Management. Ideally,  you should take 30% of efforts for Analysis + 10% of efforts for writing test case + 25% efforts for coding + 25% for testing + 10% for project management for all the FPs. Then you can calculate efforts required for all the Function Points. This is the guidelines had worked for us when we applied for one of our asp project. It may not work for all the projects. It give you some idea how the project should be estimated. If you have some better ideas, please share it with me in comments sections. I will appreciate it.

Use Cases and Usage Scenerios

As I have already explained the importance of Use Cases and Usage Scenario in my earlier post of Analyzing information. This post would throw more light on Use case and Usage scenario.  

Use cases consists of some elements  that  are responsible for functionality and behavior of the system. Users always interact with the system to do some activity and get some result. Ideally, Use cases should represent all the processes, including all the events  that can occur in all possible situations. Creating Use cases is one of the main step of requirement gathering and analyzing and it should not be ignored. It helps non-technical people to understand the system well because it does not require any technical language. It enables easy communication between End User and Stakeholders and Project team and it bring them to agree on common perception about the system. Use Case diagram is basically developed in Feasibility phase. Use case is based on what to develop concept rather than how to develop the system

A use case diagram documents the following design activities:
·       Identifying the system
·       Identifying actors
·       Defining the interactions between the actor and the system
·       Determining the system boundary

Identifying the system  When we develop the Use case, we need to identify the single system or  subsystems. A system can be a collection of many subsystems. For example,  Online Shopping System might have a subsystem that  validate and authenticate the credit card for the shopper. A collection of Use cases indicates the relationships among the subsystems that make up the system, in addition to the relationships between systems that interact with each other.Identifying actors
The actor is external entity which  interact with the system to be built for the completing an event. In sample language, Actor represents Users who interact with the system for their day to day activities. Also,  Actor can be another system or database that might  interact with subsystem. The actor is an integral part of the use case. The use case represents the interactions between an actor and the system.  An actor can be: For example, In library Management System, some of the actors are Member, Book Entry Clerk, Manager, Cashier etc.
The roles played by actors explain the need and outcome of a use case. By focusing on the actors, the design team can concentrate on how the system will be used instead of how it will be developed or implemented. Focusing on the actors helps the team to refine and further define the boundaries of the system. Defining the actors also helps to identify potential business users that need to be involved in the use case modeling effort.

What is Usage Scenarios?
Usage scenarios describe in detail a particular instance of a use case. It takes many usage scenarios to document a use case completely. Whereas use cases are diagrams, usage scenarios are narratives. Usage scenarios provide additional information about the activities and task sequences that constitute a process. Usage scenarios document the sequence of tasks. Usage scenarios depict objects in a workflow process. Objects are something that are affected by the system, something that affects the system, or something that a system needs to be aware of to function properly. For example, objects in a training center include the customer, the training course, and the sales representative. Objects provide a view of the characteristics and behavior of elements in the problem domain that is addressed by the business challenge. In the conceptual design phase, you create usage scenarios that depict the objects in the problem domain.When you develop usage scenarios, you might identify a task that must be treated as a use case. For example, in the “Register customer for course” use case, you might determine that the task sequence “Process customer payment” is a high-level use case that is part of the workflow process and has several usage  scenarios. Consequently, each usage scenario for “Register customer for course” ends with “Entering course number.” Then you create all relevant usage scenarios for the new “Process customer payment” use case. You identify the use cases that correspond to the workflow process and then develop usage scenarios that describe the task sequences for each use case. From the usage scenarios, you can determine the current state requirements.

Need of creating Current State Usage Scenarios?After you identify a use case, you can determine the different usage scenarios that can occur for the use case. You then use the information that you gathered from users to describe the different usage scenarios possible for the use case. Creating a usage scenario helps you determine if you gathered the appropriate level of information. Gathering the required amount of information for describing the current state is part  of the iterative aspect of gathering and analyzing information.

You can create scenarios for both the current and the future states of the business environment. The current state scenario depicts how business activities are currently conducted; the future state scenario presents the activities as the business wants them to be. For both states, the scenario emphasizes business processes, information, users, and tasks. In some situations, full scenarios need be developed only for use cases that are known to have many exceptions or dependencies. This allows the project
team to balance costs against the potential benefits. Use cases and scenarios should be developed iteratively, and can be discovered or continued during development work on the initial set of use cases. Although there are various ways to analyze the current business processes,  use cases and usage scenario specially effective in modeling the process. 

Use case title: Customer requests product literature
Abbreviated title: Customer requests product literature
Use case ID: UC05.1
Requirements ID: 14.1
Description: Customer wants to obtain information for a product. The customer is able to view a copy online, print a copy, or request a hard copy to be delivered by mail.
Actors: Customer
Preconditions: ·         Customer has Internet access.·         Customer has browsed to the Adventure Works Cycles Web site.·         Customer has clicked Browse Product Descriptions.·         Product information exists in the database, and the site is working properly.
Task sequence
Customer scrolls to desired product.
Customer selects product by clicking on product graphic or details.
Customer views basic product information (name, description, image, in-stock status, price, item number).
Customer clicks Need Complete Specification?
Customer views full product specification online (UC05.1.3).
Customer clicks Mail Me Full Brochure (UC05.1.1).
Customer clicks Submit.
Customer browses away from product specification.
Postconditions: The request to receive the full specification by mail is complete and saved in the database.
Unresolved issues: How should saved requests best be queued for fulfillment?If submit process fails three times, what process should be invoked?
Authority: Mike Danseglio
Modification history: Date: November 6, 2002Author: Heidi SteenDescription: Initial version

Reference : Analyzing Requirements and Defining  MS .Net Solution Architecture exam 70-300 eBook.