Requirements are Perishable Goods

A prospective client of mine is a local electronic payment hub whose principal clients are other companies that are using their services. They are a relatively large company (by local standards) and have invested a lot in engineering and formalizing the whole process. At the moment, they are CMMI level 3 appraised and are going for the level 5.

Operations are heavily compartmentalized, with high degree of specialization between the departments. For example there is “backend factory” doing the development on the legacy backend system, “frontend factory”, “UAT”, “PMO”, “QA”, “Architecture” department etc. The way they implemented the process can be best described as textbook waterfall.  It goes like this:
  • Analyst receives the requirement and enters it into the flow
  • Requirements committee assesses the requirement and produces estimation:
    • Non-requirements are sent to help desk or refused
    • Requirements are classified as projects or simple requirements
    • Information is sent to all departments in order to obtain the estimation (effort and delivery date)
    • Estimation total ($ and delivery date) is produced by summing all individual estimations and sent to a client
    • After client accepts the estimation, the Project Manager is assigned to the requirement.
  • Project Manager role is to track individual tasks that requirements was broken into and to prod and beg departments to have their task delivered first. As far as I could see, there is no transparent mechanism for managing task priorities. The initial estimation date seems to be the early factor, more priority given to those who are the most behind the deadline. Then project managers can “scale up” their requests, occasionally reaching the CEO himself. In the end, it is the employee seniority that decides the task priority.
  • It’s the different factories that implement the tasks once they can get their hands on them, according to prioritization that I just explained.
  • Since each factory is specialized and works on the single application layer, there is often some integration work to be done. This work is (reasonably enough, right?) performed by the Integration department.
  • After all this, requirement reaches a UAT departments and if it is not turned back (as it often happens) it is ready for the  production.
The reason why they are reaching out is that the process is taking too long. For the moment they are mostly preoccupied by two symptoms:
  • There is a lot of defects caught by QA (or “UAT”)
  • Producing the initial estimate is taking more than a month in average! This is a constant complaint by the customer.
During the course of our initial interview, there were some other interesting facts mentioned.
  • There are a high number of “frozen” projects. These are those projects that are put on hold in any moment of time. It is not clear how many of these are resumed (I doubt that many are resumed).
  • There are a high number of projects that have poor (even null) exploitation once they reach the production.
  • While client can opt-out from a project in the very early phase, this is not so once the project is set in motion and man-hours spent on it.
Here is the rub: Being the electronic hub, most of the company’s income is generated by “per transaction” charge. Charging transactions is their main line of business and the source of profit. While they do charge client companies for implementing different projects, they know that the main income will be generated through additional traffic that these projects will create.

Imagine the loss that is generated when projects are frozen, canceled or unused in production! How much profit and growth would a company achieve if all software they produce would to generate transactions in the production! The whole process simply reeks of waste. By insisting on implementing  initial requirements without being able to change them later on, not only are they making the life more difficult for the client, they are shooting their own foot. If these requirements do not result in software used in production by final client (not just deployed so that project can be marked as finished and payment collected), they are losing money they could earn from charging transactions. By prioritizing requirements based on how late they are, they are making it more probable that these will come to production too late. Talk about waterfall double whammy!

I can only imagine the person in charge of the project on the client side. All the trouble he would have to go into if he discovers that a requirement hasn’t been specified well initially. Or maybe the project is taking so long that initial requirements have no value. If he was to cancel or change requirement, this would surely provoke a number of questions from his superiors. It’s much better to keep quiet and get the project to “successful” finish, even though no one will ever use it.

Solution? Let customers change they requirements as they go along, prioritize requirements by their potential for generating transactions in production, work on customer development, generate multidisciplinary teams that can react quickly etc. In one work, make the whole process much more agile. Taking into account all the interests involved and all the politics generated in company as large and compartmentalized as this, it’s easier said than done.

As I mentioned, the prospective client has a formalized, engineered process and while it is lacking in the aspects of quality, it is relatively mature. But, if you take too long to get things done, being formal and disciplined is just not enough.
Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG