Siraj ’s heaven.

Imagination is more important than knowledge. -Albert Einstein

Archive for April, 2008

Project Scope Management

Posted by sirajq on April 22, 2008

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

 

Posted in SDLC | Tagged: , , , | Leave a Comment »

How to become Proactive Project Manager?

Posted by sirajq on April 15, 2008

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

Posted in SDLC | Tagged: , , , , | 3 Comments »

Project Configuration Management

Posted by sirajq on April 10, 2008

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

 

Posted in SDLC | Tagged: , , | Leave a Comment »

Defect Prevention Technique

Posted by sirajq on April 10, 2008

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.

 

Posted in SDLC | 1 Comment »

Project Risk Management

Posted by sirajq on April 9, 2008

 

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. 

 

Risk Management Process

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

 

 

 

Posted in SDLC | Tagged: | Leave a Comment »

Project Quality Management

Posted by sirajq on April 5, 2008

 

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.

 

 

 

 

 

 

Posted in SDLC | 2 Comments »

Localization in ASP.NET 2.0

Posted by sirajq on April 2, 2008

When you are developing a web site for international users, one questions instantly come to our mind which is how our web site going to support multiple language, currencies, date etc.? Thanks to ASP.Net 2.0, it made our task of making localized application simple and easier. Localization  is the process of designing and developing a software product that function for multiple cultures having different language currencies, date and time. Asp.Net 2.0 has a incredibly good features to support localizaion. These are features are self explanatory and easy to use.   A .Net web forms page have two culture values , Culture and UICulture. Culture is used to determine culture dependent function such as Date, Currency. So it is used for date formatting ,number formatting. UICulture values is used to determine which language the resources should load that is which UI string the resource should use. The two culture settings do not need to have same values. It may be different depending on the application. I will give you brief idea of developing application that support localization.  For example, we want to develop a website which should support english and french language. Functionality of the web site will be same only difference will be the language in which information will be displayed on the pages of web site.

Setting Culture and UICulture

1. Through Web.Config


<configuration>
<system.web>
<globalization fileEncoding=”utf-8″ requestEncoding=”utf-8″ responseEncoding=”utf-8″ culture=”en-US” uiCulture=”frFR” />
</system.web></configuration>
2. In Code-inline (aspx) Page

<%@ Page UICulture=”fr” Culture=”en-US” ….%>

3. In Code-Behind (aspx.cs) Page

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture (“fr-FR”);
Thread.CurrentThread.CurrentUICulture=new CultureInfo(“fr-FR”);

 Resources:

ASP.NET wont automatically translate the contents in one language to another language by using Culture. For this we need to put our language specific labels, messages, title in resources file and ASP.Net will load this information from resource file depending on the setting of UICulture and key provided to Resource Manager object. Each entry in the resource file will have a resource key which help us to identify and read the message from the resource fileResources represents embedded data such as strings or images, which can be retrieved during runtime and displayed in the user interface. Resource Management is a feature of .NET framework which is used to extract localized element from source code and to store them with a string key as resources . At runtime, ResourceManager class instance is used to resolve key to the original resource or localized version. Resources can be stored as an independent file or part of an assembly.  ResourceWriter and resgen.exe can be used to create .resources file. To include .resources file inside an assembly use related compiler switch or Al.exe.

Create Resource Text Files:

In resource.en-US.txt
Test = Hello there, friend!In resource.fr-FR.txt
Test = Bonjour là, ami!

Generate .resources file:

Goto VisualStudio.Net command prompt and use resgen command utility to generate .resources file resgen resource.en-US.txt
resgen resource.fr-FR.txtThis commands will create .resources file.

In TestGlobalization.aspx Page

<asp:RadioButtonList id=”RadioButtonList1″ style=”Z-INDEX: 101; LEFT:144px; POSITION: absolute; TOP: 144px” runat=”server”
AutoPostBack=”True”>
<asp:ListItem Value=”en-US” Selected=”True”>English</asp:ListItem>
<asp:ListItem Value=”fr-FR”>French</asp:ListItem>
</asp:RadioButtonList>

In TestGlobalization.aspx.cs Page, on Page_Load Event

CultureInfo objCI = new CultureInfo ( RadioButtonList1 .SelectedValue .ToString ()) ;
Thread.CurrentThread.CurrentCulture = objCI;
Thread.CurrentThread.CurrentUICulture = objCI;
ResourceManager rm = ResourceManager .CreateFileBasedResourceManager (“resource”, Server.MapPath(“resources”) + Path.DirectorySeparatorChar, null);
Response.Write( rm.GetString(“Test”));



You can read details explaination of localization in Asp.Net 2.0 at   following links


http://www.ondotnet.com/pub/a/dotnet/2005/08/08/localizingaspnet20.html?page=1

 

 http://aspalliance.com/821
http://www.codeproject.com/KB/aspnet/localizationByVivekTakur.aspx

Posted in Asp.net | Leave a Comment »