Business Case (Is it a good idea to modify an Activity?)

Today, we also covered Business Cases, it is an interesting subject, it basically tells you to compare projects using the following criteria:

• Total Activity Disfunctionality
• Total Activity Impact
• Total Activity Factibility

If Impact and Factibility and Disfunctionality are high, then it is a good idea to go ahead with the project, on the other hand, if, for example Factibility is low, then, it would be impossible to really build the project, or if the Impact level is very low, then it might be easy to do it (hi factibility) but i will not help the organization much, so, it will not be a good idea to waste time building the project. If Disfunctionality is low, that means that the activity actually works really good, so, typically the impact of your changes will not be high.
(Mmmm, I see some kind of relationship between Disfunctionality and Impact)

The project triangle

In project management a very important concept is that of the project triangle: Scope, Resources, and Time, it is impossible to have more than two of them.
I have had problems with this triangle.... always, typically because there is not time, and there is no money (Resources) and the Scope, well the Scope always increases.
The main problem in my experience is that not a lot of people has heard of this triangle, and those that do, say, well, it is a nice idea, but the reality of this project is that we need this done with cheaply, for tomorrow, and with unexperience personnel.
When the projects is "Tipically Succesful" it is because it is not too late, or hasn't exceeded the budget too much... or the scope was not too insuficient.

The problem is that everybody in software developerment needs to realize that it is not possible to control more than 2 of this factors. For example:

If you have to do everything in a rush, scope will suffer, and if scope doesn't suffer, then costs will increase...

Perhaps somebody (I?) should create an interactive version of this triangle... one that, when changed 2 factors tells you the implications in the third.

I am starting to think that the project triangle is somewhat similar to radar charts....

Areas of Oportunity

1. Take advantage of Eventum/Bugzilla and use it to feed Construx Extimate (Metrics, Estimation)
2. Take advantage of Construx Estimate to feed DotProject in a more accurate way (Metrics, Estimation)
   
3. Use the curse as a fundation to justify the use of configuration management tools
4. Give courses to increase technical level.
5. Implemente a processs lifecycle for the development of each feature (covering configuration management, architecture, etc) that will help to make estimates more accurate.
   

Software Engineering the State of the Art

Today I started my course on project management, and my instructor gave me this very interesting link: Software Engineering the State of the Art

Alphora Dataphor is OpenSource!

Now that AlphoraDataphor is opensource, I believe a relational reborn could come in the near future... I have been reading the manuals and, while I am an object weenie let me tell you all that I think Dataphor is a very exciting technology I hope it finds the way to make True relational database a buzz word like Ruby and that finally forces big companies like Oracle to make databases truly relational.

Short projects, not short team lifespan

Today, I had an epiphany, I realized that while project must be short, teams should last a lot of time.

It is infinitesimal, and Done is the Limit

Today, I was reading some articles in InfoQ,,, one of them called my attention:

InfoQ: Does "Done" Mean "Shippable"?

It made remember a blog post a wrote months ago titled "When will that feature in your system be finished"
and here I am wondering... why if this kind of problem is so common... why if it seems to be happening to everyone...
why we don't have some kind of manual to help ourselves to explain others that saying something "is done" has a very
different meaning for different people... for different situations,,,, and, maybe the right answer is that it is never done...

A good system should be able to evolve.... to get new features, to make the current ones more robust...to improve...
I should never be "done" in an static way... it should be able to grow organically... it comes closer and closer to being "done" but it never gets really done... (we could even argue a "done" system is an almost dead system, because it would be a system that can not improve anymore)

Maybe the problem is that reaching the "done" state in software development is like trying to reach a limit in math, we get close, and closer, but if we do things right, we never reach the done state, because we always have things to add, or things to improve.