Monitoring an Ongoing project development team productivity

ProjectCodeMeter

Monitoring an Ongoing project development team productivity

This process enables actively monitoring the progress of software development, by adding up multiple analysis measurement results (called milestones). It is done by comparing the previous version of the project to the current one, accumulating the time and cost delta (difference) between the two versions.
Only when the software is in this mode, each analysis will be added to the History Report, and an auto-backup of the source files will be saved into the ".Previous" sub-folder of your project folder.
The process is a variant of Cumulative Differential Analysis which allows to more accurately measure software projects, including those developed using Agile lifecycle methodologies.
It is suitable for measuring productivity of both single programmers and development teams.

Step by step instructions:
1. Make sure you don't have any open ProjectCodeMeter report files in your spreadsheet or browser, as these files will be updated. If you want to start a new history tracking, simply rename or delete the old History Report file.
2. Put on your local disk a folder with the most current project source version (excluding any auto generated files, files created by 3rd party, files taken from previous projects) if you already have such folder from former analysis milestone, then use it instead and copy the latest version of the source files over it.
3. Select this folder into the Project Folder textbox
4. Click the Differential Comparison checkbox to enable checking only revision differences
5. Clear the Old Version Folder textbox, so that the analysis will be made against the auto-backup version, and an auto-backup will be created after the first milestone (ProjectCodeMeter will automatically fill in this textbox later with the auto-backup folder)
6. Optionally, set the "When analysis ends:" option to "Open Differential History Report" as the History Report is the most relevant in this process
7. Select the Settings describing the current version of the project (you should usually ask your developer for the Quality Guarantee setting, and).
8. Click "Analyze", when the analysis process finishes the results for this milestone will be shown at the bottom right summary screen, While results for the overall project history will be written to the History Report file, which should now open automatically.
9. On the first analysis, Change the date of the first milestone in the table (the one with all 0 values) to the date the development started, so that Project Span will be correctly measured (in the History Report file).
10. If the source code analyzed is a skeleton taken from previous projects or a third party, and should not be included in the effort history, simply delete the current milestone row (last row on the table).
11. Fill in the number of developers who worked simultaneously on this milestone. For example, if the previous milestone was checked last week and was made by 1 developer, and at the beginning of this week you hired another developer, and both of them worked at developing the source code for the this weeks milestone, then enter 2 in this milestones "Developers" column (the previous milestone will still have 1 in its "Developers" column)
12. Optionally, if you know the actual time it took to develop this project revision from the previous version milestone, you can input the number (in hours) in the Actual Time column at the end of the milestone row, this will allow you to see the Average Actual Productivity of your development team (indicated in that report) which can give you a more accurate and customizable productivity rating than Average Span Productivity.

The best practice is to analyze the projects source code weekly.
Each milestone has its own Span Productivity (and if available, also Actual Productivity), these show how well your development team performs comparing to the APPW statistical model of an average development team. As your team is probably faster or slower than average, it is recommended you gather at least 4 weekly milestones before deriving any conclusions. For monitoring and detecting productivity drops (or increases), look at the Span Prod. Delta (and if available, also Actual Prod. Delta) to see changes (delta) in productivity for this milestone. A positive value means increase in productivity, while negative values indicate a drop. It is recommended to look into the reasons behind significant increases (above 5) or drops (below -5), which development productivity improvement steps to take.

Look at the Average Span Productivity (or if available the Average Actual Productivity) percentage of the History Report to see how well your development team performs comparing to the APPW statistical model of an average development team. A value of 100 indicated that the development team productivity is exactly as expected (according to the source code produced during the project duration), As higher values indicate higher productivity than average. In case the value drops significantly and steadily below 100, the development process is less efficient than the average, so it is recommended to see Productivity improvement tips.