What's Project Management?
Project management is the process of leading the work of a team to obtain goals and meet success criteria at a specified time. The primary challenge of project management is to achieve all the project objectives within the given constraints.
This is what Google tells you.
What's a normal Manager?
A person in charge, who is:
- Disturbance Handler
What's a Project Manager?
A person in charge of a project, who is:
- Comic relief
- Risk manager
- Problem solving
How to determine the quality of a programmer?
The quality defined in numbers
The productivity Number for a Programmer
A programmer writes code, not? How can you tell how many lines of code (LOC) a programmer writes? Simple, by counting them at the end of the day or by the end of the allocation, whatever comes first.
Now it has come. The project manager (or team leader), is recording the number of lines of code for that assignment and/or day.
The project manager receives that information, and he or she can already generate reports and see if there is something weird going on with his project.
Or better, the project manager (PM) can create a number, which the PM can call the Productivity Number. We calculate the productivity number as a daily average and make it part of the programmer's company's profile.
The Quality Number for a Programmer
As a PM, I hope you have Quality Control (QC). If not, in God's name, get yourself a QC department or team with a QC manager.
The programmer is producing code. You got that from the previous section. The PM wants to know if there are mistakes made in the code. The PM also wants to know if the code indeed does what's specified. I hope you get it. Hunt for bugs (or defects).
Your QC team is getting involved and test what the programmer had programmed. And they test for crashes, bugs, etc. If the program is indeed doing what the specs have stated.
In many cases, in practice, the testing of the code will fail, because it's part of something bigger, still in development, or it's a part, add-on, plugin, library, etc. In those cases it's very normal that the programmer, as part of the assignment, also programs the temporary testing application for himself (and for the QC).
The QC is testing the program from the programmer and the results are coming back in the form of a bug report.
Besides that the programmer needs to fix those bugs or not, the PM has valuable information with those bug reports. He also registers the number of bugs for that specific module or program, part, plugin or whatever it is, and for the programmer in question.
If this PM is doing this every single day, every single program or module or whatever they are programming, and he puts this in a spreadsheet, he'll be astonished with that information!
You remember information?
Data is a collection of facts. Information is how you understand those facts in context. Data is unorganized, while information is structured or organized. Data generally includes the raw forms of numbers, statements, and characters.
Or with other words, the information will show interesting understandings:
- When you make a small calculation, such as, how many defects were found in an amount of lines of code for a programmer. For example, an average number of defects (bugs, faults, whatever) in 1,000 lines of code (a programmer has produced).
- That number (1,000 line of code) can be adapted for your project and/or organization in something smaller or bigger.
- You can guess, this number can be the quality number (for the programmer in question). That number can be added to the professional profile of the programmer in question.
Examples are like
- Programmer X has a quality of 13 bugs with 500 lines of code. It's written like 13/500.
- Programmer Y has a quality of 16 bugs with 500 lines of code. So 16/500.
- Programmer Z, Z1 and Z2 have the quality indicators of 20/500, 12/500 and 6/500.
Predicting the number of bugs
With a quality indicator for the programmer, you can already predict how many defects we get hereafter (when you have an idea how many lines of code you need for the next program, module, plugin, etc.)
Predicting the number of lines of code for a program or part of it in the future is really possible. You use - as a PM - a so called program library. The US defense are publishing those program libraries in order to determine how large (and how long) a project will take for their sub-contractors.
A program library is a large file (book), which is nothing else than a listing of functions of any program, which also writes the number of lines of code, the durations (slow, medium and fast) for each function and can be used to calculate the size and durations for any (IT) project! I will write an article about that after this.
- Create a login screen:
- Lines of code: 13
- Fast time: 20 minutes
- Medium time: 45 minutes
- Slow time: 90 minutes
- Create a login screen:
More about this in a later article.
When the expected program is about 1,000 lines of code, programmer X will produce likely 26 bugs. This number is crucial for the QC manager, because the QC will have an idea what to expect.
I am really finished with talking about statistics in a project and some ideas on how to use it to verify quality and forecast bugs in a future program.
I was involved as a Project Manager with hundreds of project members from IBM, Microsoft, AT&T, Yadda Yadda, Ericsson, Bull, Philips, and I always used the statistics in my projects.
The process of design, from the very beginning until the delivery of the project, was calculated from A till Z. Everything was statistically analyzed before, during and the end (post project). With that data, I could do another project with those talents much better and faster than ever before.
Each manager, team leader, project leader, secretary, programmer, graphical designer, DBA, QC tester, GUI designer, even the cleaners and the toilet boy, etc. Had quality and productivity numbers. Each module, each function, each program had the history statistics too. All QC work was performed with the help of statistics. All potential problems were detected from the beginning and resolved very early on.
The scheduling (made before any programming was done) was very accurate and worked till the last day of the project.
Throughout the project, I published quality and project productivity numbers in the form of a number between 0 and 10 (the number 10 indicated that the project functions perfectly). Those numbers were not given, but calculated.
I used those indicators as PR for the organization management, for the customers and the team to indicate their successes and as the means to interfere. Better, those numbers immediately told me about the problem and what was happening. That is a requirement for larger projects with hundreds or even thousands of project members involved.
For more alternative, take a look about Projects with common sense.