The software industry is associated with the most innovative techniques and technologies, but at the end it is an artisan art activity. Bill Gates once said, “Software is a great combination between artistry and engineering." Two software solutions with the same functionalities can externally be similar, but internally can be very different; for sure that one of them has a better performance, is easier to maintain in the future, provides the same functionalities with less code, has less error risks and has been built in a more clever way.

It will depend, in part, on the technical knowledge of the teams involved in creating the solution, on the quality and clarity of the requirements, and on the two magic words that are involved in creating a technical IT solution as in managing IT projects: “common sense” applied to all situations. So simple and sometimes so difficult to accomplish, especially when decisions or actions are not taken from the technical point of view, conflicts of interest exist, lack of knowledge, and a set of grey concepts that can contribute in transforming brilliant IT products (internal or external) into mediocre solutions.

It is fascinating, and at the same time essential, to add the word excellence: “common sense excellence.” To give the best quality to the customer, the best product, and in fact, that the customer (so external if you are an IT company, or your company if you are an IT department) receives the greatest value from an IT solution and at the best price are strategic objectives that might be specific and measurable, among others (SMART goals: Specific, Measurable, Achievable, Relevant, and Time bound).

It is essential to always have in mind that Information Technology must provide the highest business value and competitive differentiators to companies. IT projects are just time temporal things to create, maintain or enhance products. On the other hand, IT products can provide “strategic value” to the business, or just complete processes faster or cheaper. Measure, monitor and to have concrete and clear targets of this value might be a must.


Agile: a new “springtime” in project management, born in a ski resort

In mid-February of 2001, in the Snowbird ski resort, Utah, USA, seventeen software development thinkers created the “Manifesto for Agile Software Development”, and at the end of this same year the Agile Alliance was created as a non-profit organization with the aim to promote the Agile software development based on the Agile Manifesto.

This Agile Manifesto, as principles or commandments, is just common sense and excellence, perhaps a few lost for someone in the Project Management world, moving from the traditional waterfall concept to an interaction model. This well-known Manifesto includes twelve high level guidelines that are essential in providing value to the customer (“our highest priority is to satisfy the customer through early and continuous delivery of valuable software”), to enforce the importance and to correctly manage the requirements and its changes so that the product fits real customer needs (“Welcome changing requirements, even late in development”, “Deliver working software frequently”), to work correctly (“Business people and developers must work together daily throughout the project”, “Build projects around motivated individuals”), to have commitment in all levels (“The sponsors, developers, and users should be able to maintain a constant pace indefinitely”), the importance of the “Continuous attention to technical excellence and good design”, and the importance of “Simplicity, the art of maximizing the amount of work not done.”

Perhaps those words are nothing new looking through the “common sense excellence” glasses, but sometimes it is important to remind us of a set of important things in order to always have the polar north in view.

Certainly you are familiar with the “CHAOS report” by the Standish Group. This interesting report has been produced yearly for more than 20 years and has analyzed thousands of IT projects around the world, from small to extremely big ones. The main focus of this periodical report is to analyze the reasons for why projects succeed and fail.

We can say that history tends to repeat itself. In the most recent report, the three major reasons of project success are user involvement, executive sponsorship, and emotional maturity (team’s behaviors, skills, etc.) Turning back the clock two decades, the reasons in the nineties were user involvement, executive management support, and a clear statement of requirements. In the opposite side, the top factors of projects cancelled were incomplete requirements, lack of user involvement, and lack of resources. The actual technology, apart from mainframe aspects, is far from the one existing twenty years ago, but the main causes of project success and failure are almost the same.

A clear, but not new, finding from this report is that the rate of IT projects cancelled, completed but over-budget, delayed, or with fewer functionalities than expected is much higher in very large or large IT projects than in small ones. The IT Project success is inversely proportional to the project size. Small projects usually are associated with the word “success” and on the opposite side extremely large projects are closer to the word “cancelled.” We could say that the Agile Manifesto and the CHAOS report have a clear traceability. This is one of the “dividing to rule” keys of the Agile: break projects into small parts of user functionalities (user stories), prioritize them, and deliver them in short time and regularly (iterations). Another finding in recent years is that the percentage of successful projects in Agile is much higher than in Waterfall projects.

There is no doubt that the “Agile” concept brought a springtime in the project management area and in a few years has changed how IT projects are managed.


Project, Product, Effort and Size

It is extremely important to separate the concepts “project” and “product” and to manage and measure them correctly. This simple idea is sometimes far from the common practice in small companies as in big ones; it is not uncommon to see this project concept as an isolated concept in which the IT product created or enhanced is not measured; all the measures are focused only on the project or even on the contract concept. The same software solution, product or enhancement can be created under different contract types, with a waterfall methodology approach or with Agile, in small iterations where the customer can see and check results in a short time period. But in the end, in waterfall, in Agile, in a fixed price contract, in a time and material approach, in one big project or divided in dozens of small projects, or under much more models, an IT software product will be created. This software product will provide a value to the company and will have a concrete cost (regardless methodology use, financial contract, number of contracts, number of providers for big projects, or number of projects).

If it is essential to distinguish between product and project as two completely different things, it is not less important to distinguish between effort (time) and size (functionality provided to the customer) and that nobody falls into the trap -perhaps the less familiars in those topics- that more effort is equivalent to more size or vice-versa as a standard rule; it could be or it could not be. Anyway, it is curious: I have not seen any project that does not manage the “effort” (days, months, hours) or the “cost”, but I have seen too many projects where the “size” is omitted.

Story Points are the most used method to calculate the effort to develop a story: the amount of work to do, complexity, and risk or uncertainty in this work, but it is important to take into account that it is an arbitrary measure. We can say that two different teams, even in the same company, can arrive at two different number of Story Points because it can be very easy for one to do something and for others it can be extremely complex. This metric provides an isolate help for the estimation and planning process, for tracking stories, and for future projections, but not much more out of a story perspective.

Based on the Capers Jones “Thirteen software metrics criteria” idea, Story Points meet only 4 of 13 criteria: they are not standardized (every story is different), they are highly ambiguous, they do not have adequate published data, they do not have tools available for new projects nor for legacy projects, they do not have conversion rules for related metrics, they cannot deal with all deliverables, they do not support all kinds of software, and they do not support reusable artifacts. The most typical Agile metrics fit only four of the thirteen criteria.

Agile metrics, and even the traditional project metrics, might open the doors to the product concept perspective and measure it; measure that will be taken as base for the most strategic metrics. If this is not done, all the subsequent metrics will be arbitrary ad hoc numbers. In fact, a same IT product, regardless of whether it has been built using an Agile or waterfall approach, will have the same size. The method used to manage the project, or the contract type, are just mechanisms to create products or to enhance existing ones. With standard worldwide metrics, we can compare even in a same box products built using Agile and products created using other methods or contract types.


The perfect coexistence: Agile and Functional Size

The meaning of the noun “complement” is something that completes or makes perfect. The metric “Application Size”, using ISO recognized and standard methods, is the perfect and necessary complement to the Agile metrics: here is the magic combination between product metrics and project management metrics; In fact, the customer receives an IT product, not a project. We, as customers, when buying a supermarket product, for example, we analyze (or have analyzed previously because we are users of this product) how is the product, the quantity that we receive, its quality, the price and other factors such as the brand reputation, but by general rule we are not interested (and even it is a black box for us) in how the company manages internal projects, the methodology, the tools or the machinery used to create this product. As a customer, we put the focus basically in the product that we receive and the price. Even more, we compare the price per kilo or liter, for helping to compare products based on size. The same thing generally happens when we, for example, buy some concrete standard software. Then, why as the user or customer we put so much emphasis in how the IT product is built from the project management perspective and the product itself is often not measured?

The standard size is measured using FSM (Functional Size Measurement) ISO/IEC recognized methods, and IFPUG Functional Size is considered the most worldwide used and at the same time the father of other standard ones. But it is interesting to differentiate between ISO/IEC worldwide recognized methods: IFPUG (International Function Point Users Group), FiSMA (Finnish Software Measurement Association), Nesma (Nederlandse Software Metrieken Associatie), COSMIC (Common Software Measurement International Consortium), and Mk II (UK Software Metrics Association) that can be viewed as competitors or rivals but in fact they have strong links and cooperation to bring insights and support to the IT management and projects world, sponsored by non-profit organizations, and other not standard methods created by private companies. We can say that as more used and universal is the method we use much more better for reference and comparisons purposes, for example.

With the usage of these product metrics, it bypasses the project concept and the product itself can be measured and can be compared (without taking into account the words Agile, Waterfall, Incremental, etc.) internally, externally, and with a set of worldwide standard repositories. Perhaps in the case of Agile, so in waterfall, different projects and stories will be converted into a product. By combining project and product information, we will have fascinating information and exciting conclusions. Here is where takes more importance the word “product” than “project” from the strategic, product owner, or C-level executive point of view. What is the product that I receive and what is its cost?

Perhaps there is a perception that Agile project metrics have its own rhythm and purpose, far different than the traditional concepts, estimation process and measures, and even sometimes there is an apparent, or less apparent, conflict between most classical project IT management styles and new ones; different people tries to defend positions, specialties, sometimes for technical and common sense reasons but perhaps other times with just personal, group, or team profit reasons.

It is essential that the work produced was measured; so, its quality, productivity and price, as mentioned, independently of how the project or projects to build the project have been managed internally. Agile must not be seen as an ecosystem, but as an interesting tool to build products with a more effective way of applying the Agile Manifesto, a synonym for common sense in managing projects.