Control your IT Projects with Statistics

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.

14% of IT projects fail

According to a 2017 report from the Project Management Institute (PMI), 14 percent of IT projects fail. However, that number only represents the total failures. Of the projects that didn't fail outright, 31 percent didn't meet their goals, 43 percent exceeded their initial budgets, and 49 percent were late.

Inaccurate requirements

Requirements often cause projects to fail when sponsors write specification documents in a vacuum, leaving the development team out of the process.

Uninvolved project sponsors

Another big cause of failure arises when development happens in a vacuum. Instead of staying involved during the development phase, project sponsors hand off the requirements and wait for teams to deliver a finished product.

Inaccurate estimates

In the earliest phases of a project, estimates are—at best—educated guesses. Because teams know so little about project requirements and dependencies, cost and time estimates may be four times more—or four times less—than actual implementation costs and timeframes.

Shifting project objectives

Changing project objectives are to blame for 36 percent of failed projects, but changes in the plan don’t have to lead to failure. Minimize this risk by reducing the timeframe of plans.

Unexpected risks

Unexpected risks account for 27 percent of project failures, but they shouldn’t. The solution for unexpected risks is the same as the solution for inaccurate estimates. To avoid project failure due to unexpected risks, estimations need to reflect both known and unknown risks.

Dependency delays

For large and/or complex IT projects, there are often multiple development teams involved. Sometimes dependencies are internal teams from other departments that own and manage specific platforms or services, and sometimes they’re vendor teams customizing a product or service the company purchased.

Not enough resources

Project managers often use the word “resources” to refer to people, so “not enough resources” refers to not having enough people to complete the work for a project. It accounts for 22 percent of failed projects.

Poor project management

Creating a plan for a project isn’t enough. Someone must monitor the plan. That person can be a project manager, IT manager, or Scrum Master—who doesn’t matter as much as the fact that someone is monitoring progress.

Team member procrastination

Accounting for 11 percent of failed projects, team member procrastination goes hand-in-hand with poor project management. If developers are procrastinating—or if the people the developers are depending on aren’t supplying answers, code, or services—it should be obvious that the project plan is headed off track.

What's a normal Manager?

A person in charge, who is:

  1. Administrator
  2. Leader
  3. Teacher
  4. Figurehead
  5. Disturbance Handler
  6. Negotiator
  7. Entrepreneur
  8. Spokesperson
  9. Disseminator

What's a Project Manager?

A person in charge of a project, who is:

  1. Administrator
  2. Documentor
  3. Leader
  4. Comic relief
  5. Communicator
  6. Risk manager
  7. Problem solving
  8. Negotiator
  9. Disseminator
Programmer

Programmer

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 factsInformation 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.

For example:

      • Create a login screen: 
        • Lines of code: 13
        • Fast time: 20 minutes
        • Medium time: 45 minutes
        • Slow time: 90 minutes

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.

Statistics

Statistics

More statistics

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.

Leave a Reply, please

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyrights (c) 2020 Wim Vincken | Copyright Notice | Privacy Policy | Resume | Terms & Conditions | What's New | Refund Policy
InterServer Web Hosting and VPS
%d bloggers like this: