Tag Archives: management

Why fixed-price does not work for Web Projects

Since I became a Freelancer Web Developer, I established that the Mission in my Strategic plan was “to provide high Quality customized web apps to my customers”. Just notice that the main word is QUALITY.

The best approach I know to explain the concept of Quality in a Web Project is the Broken Iron Triangle:

  • Scope: are features and functionality expected
  • Resources: Cost
  • Schedule: time to implement these features

ironTriangle

 

Here explains how a project is broken when you fix this three features. And how Agile methodologies (with sprints and communication) maintain the triangle flexible in order to have successful experiences.

“In many ways, we really need to question the ethics of “fixed-price” IT projects.” Scott W. Ambler. All project risks are moved from the Customer to Developer. Driving to a bad experience for at least one side of this relationship.

In my opinion, you could fix costs if you can fix Scope (features) from the beginning. But this never happens because:

  • Features are often subjective or poorly defined. i.e.: While Developer is thinking in a button to remove a message, Owner is thinking on Drag&Drop feature compatible with mobiles.
  • New features appears in the process of development
  • Feature can be underestimate or overestimate. Depends on the quality of code under the hood, the developed libraries or if you have to make it from scratch.

Sometimes the Owner (customer) gives you a set of features, and ask for an ‘estimation’. Where you fix features, cost (fix price) and number of hours that this will take. You are frozen the triangle!! . Under this ‘estimation’ document starts a Developer/Customer relationship which will finish in a failing project.

Scope is never fixed from the beginning (never), this makes impossible fix cost/time without an impact in the QUALITY of the project.

I cannot deliver poor Quality projects, due to my business strategy. This is the reason why I do not work fixed-price, instead, I work on hourly basis (N hours worked, N hours paid).

When a Customer asks me for an “estimation” (cost, fixed-price), I send a plan: features and time to implement them. And I warn them that ‘this is not a budget, it is just a work plan for your project, and schedule could vary’.

Equipos de Desarrollo de Software

En este artículo describiré mi forma de ver la gestión de equipos de desarrollo de software en particular. Como se debe articular un  grupo de desarrollo de Software para:

  • Tener una forma de trabajo sencilla de entender y aceptar por el equipo
  • Trabajar de forma eficiente:  capacidad de medir el tiempo de desarrollo y tomar decisiones para mejorarlo
  • Cubrir varios proyectos a la vez por un mismo equipo
  • Equipo distribuido geográficamente

Continue reading Equipos de Desarrollo de Software

Software Development Teams

At this post I will describe my point of view about the Team Management, and in depth Software Development Teams. How we must build a team for:

  • Having work rules simply to understand and accept by the team.
  • Working efficient: capacity to measure the development time and take decisions to improve.
  • Covering many projects at same time by the same team.
  • Geographically distributed team.

Continue reading Software Development Teams