Why commit to quality?

Colombia does not have a developed market for software. In most companies the person in charge of buying software is the same person that buys the soap, and buy it using similar criteria.

Quality in software is not understood, and developers have to do not one extra mile, but ten extra miles just to have them accept simple suggestions to avoid petty requirements that will affect significantly the maintainability of huge applications. Most clients haven´t even heard of maintainability as a concept.

You can loose your mind trying to explain the difference between a defect and a change and why you will correct defects but will not implement changes for free. And the concept of controlling changes seems to your client as a bad way to ask for more money.

If complete mess is the rule, why bother implementing a costly maturity model to guaranty quality in processes and products for clients that will not appreciate it and consider it as bureaucracy that increase the cost?

Just because you know maintainable and reusable software will save you money in the log run. Eventually you will move into the maintenance phase or build a similar system and the fact that you can reuse the documents, design or code and make your life easier will be worthy.

Normalize, but not too much

 Its common to have understaffed projects. People get recruited just when the team starts to get behind, but not before in an attempt from administrative staff to save some money. If team members can barely finish their jobs on time, they are not very interested in making advance reports or help you define how much time it will require the next task. They are tired, and they don’t see the point, since their perception is that the job gets done just because they don’t get to see their families. In this scenario is quite difficult to gather information for planning and control.

Still, if you are at the PMO, you are aware that knowing the status of the project is as important as doing the job. That is why it is your job.

How to do it? I found that adapting to the team worked properly, and try to find information in the format that is more natural to the person doing the job. Some people have organized tables where they keep track of everything, some just keep the record in a board with post-its. I just took their particular methodology, analyze it and talk them into including additional information I needed. For example, making the reports with the same periodicity or adding one more field that will allow me to have the statistics I needed for the reports.

I was able to get normalized data from all fronts of the project without having every team member filling specific formats. It just worked for me, and I guess for them, since they never felt my reports to be a burden.

 

Just a new remainder that projects are made by people, and that your need to normalize PM data should never imply you have to normalize the people you work with.

Estimations

I remember the first time I heard about Delphi Estimation*. It was my first undergrad course on software engineering. I couldn't stop laughing for a while, how can you base the whole project plan on some persons guess? It sounded so stupid, I kept making jokes about it for a while.

Many years later I found my self having a great deal of respect for estimations based on experienced persons "guesses". Delphi method just growed on me, without me even noticing.

I can now see at a proposal and just know if the estimates are good or not, by heart, I just know. During the last decade I acummulated experience and I am able to classify requirements by risk, know what can be done fast and where the programmers are being just too optimistic, in mi head in minutes.

But this gut feeling wasn't given to me by the gods as a gift, it was built with hard work. I have records of times of the work I have done, for years. Every day I record how much time I spent in each project or activity. Not histericaly, with seconds, but just a rought count each day. Every month I take an hour to summarice it and check if my estimates were correct when I planned my activities. Some times my estimates where acurate, some times they weren't. I learned from the mistake and managed to improve my estimates for next month.
I then started doing the same thing with other's people's work. I created a way to classify requirements by complexity (a personal simplification of the function points, that latter learned, are called use case points). I used to estimate how much time a team needed to develop a set of classified requirements. Then I measured, and compare my "guess" to reality and learned from the mistake. I made this for years and still do it, every day, even with the smallest simple task (like checking expenses from a trip, or reviewing a report).

I learned this wonderfull trick in the same class where I learned the Delphi method. I was "forced" to used the PSP (Personal Software Process) that includes keeping an engineering journal with notes of your work and time taken by different activities. My journal was then a ridiculously pink Hello Kitty notebook, now I just keep it all in google docs files. I will record in a while that this post took me about 40 minutes to write (including finding the magic eight ball picture), and hope that after the 5 minutes it took you to read it, you are curious enough to check the PSP and keep a journal. Believe me, its worth every second spent on it.


* Sorry about including a Wikipedia link as a reference, couldn't find a better link to explain the Delphi Estimation. If you have a better reference, please let me know, I will gladly replace the link.