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.