How do we work?
IT project methodology

As the foundation of our IT project methodology, at Binovo we subscribe to the Manifesto for Agile Software Development.

Discover Binovo

IT project methodology

We use the term traditional project management to describe the management of projects with the following characteristics: a fixed set of requirements or a fixed budget. These projects have a high failure rate, and the reasons for failure vary:

The set of requirements is not really fixed. The client is unable to list all of their needs in sufficient detail, and the supplier is unable to correctly anticipate the scale of the problem to be solved. As a result, the client’s expectations are not met, and deadlines and costs deviate far more than is reasonable. Generally, the client ends up having to pay more, or the supplier ends up losing money, in order to get the client to accept what is delivered.

Software development is not construction, but design. Entire forests have been felled to produce books on software engineering, software construction and the software factory. Pompous names for theories formulated by people who have never developed software in the real world. Software development lacks the repeatability, measurability and predictability of construction. It lacks them because developing software is designing it (equivalent to the design and technical blueprints in construction, only on a much larger scale), whereas building software is compiling and/or installing it. Programming is designing, regardless of how much prior design detail has been produced. Design decisions are always being made when something is programmed. This means that the time needed to complete a development is highly unpredictable, especially when detailed requirements are not available, but even when they are, because carrying out a sufficiently exhaustive analysis of the requirements amounts to designing the solution.

Expectations are created in the client that cannot be met. We always tell the client that we will meet the deadlines and that the system will do everything they want (and that it will be very cheap, too!). Deadlines are never met and the system never does everything the client wants, because as soon as the client sees the application, they come up with new things it should do. The client has no control over the project costs: what the client has is a blank cheque, because they have been given a cold, simple and clear figure for what the project will cost and will demand that the application do what they think it should do down to the last detail. The client is not told that a given detail may be very costly; for the good of the project, functionality must always be weighed against cost.

The client’s needs change. The client’s needs may have changed because the company or its environment has changed, or because other, more interesting possibilities have come to light.

Want to know more?
Metodología de proyectos TI | Binovo

Manifesto for Agile Software Development

At Binovo we subscribe to the Manifesto for Agile Software Development, and so we value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

While there is value in the items on the right, we believe the items on the left have more. To that end, we follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • We welcome changing requirements, even late in development. We believe that change is necessary for our customers’ competitive advantage.
  • We deliver working software frequently, from every 2 weeks to every 2 months, with a preference for the shorter timescale.
    Business people and developers must work together daily throughout the project.
  • We build projects around motivated individuals. We give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. Sponsors, developers and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity, the art of maximizing the amount of work not done, is essential.
  • The best architectures, requirements and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.