Before vacation, I promised myself to describe the possible ways to deal with the current risks of IT projects, which I mentioned in the previous post.

In terms of the risk of insufficient buyer and provider project maturity (ability to deliver and ability to absorb) the natural solution seems to have mutual rating of both parties. It is happening on  booking.com (single-sided), popular RPGs, and even Uber. Why should rating not be possible in IT?

One could speculate, whether the rating should be performed in a formalized way by a trusted third-party organization as a post-mortem assessment or it should be performed by project parties in a less formalized way and just spread around a few marks or qualities.

For public tenders formal rating would be more beneficial, as the rating level of the bidder could be included in non-economic criteria. However, it requires much more effort to organize and ensure a neutral assessment – especially when dealing with problematic projects.

I would therefore speculate that non-formal rating will be introduced first.

The rating idea assumes that future contracts will have a similar form as the current ones. This must not happen (linear approximation curse 😊). I will try to describe it in a separate post, but I think the rating will be beneficial at minimum in some of the future contract types.

And obviously, the rating will not magically increase the maturity of both parties. But it will help them to prepare for the project and will provide some feedback.

To deal with insufficiently defined scope and balancing problems (scope-time-funding) we need a deeper formalization of requirements not only focusing on system requirements instead of business requirements but also describing the expected delivery artifacts or at minimum artifact stereotypes. For example, the final requirement set for a standard database entry interactive application should describe the GUI applications/layers with the business views included, the backend business functions to be provided, integration services, and additional data storage with its CRUD functions. Such requirements do not leave much space for further discussions and let the effort be precisely calculated.

Notice – the current complexity assessment methods i.e. the Cosmic FP or IFPUG are focused on user perspective and abstract from technical aspects of the specific solution. They help to measure the complexity of the system but need localizations to help calculate the effort in a specific IT system.

So the future of IT in terms of requirement specification will be a further formalization of the system requirements, which may be done maybe even by a separate team before the implementation contract.

To deal with unbalanced projects we need at first a precise scope definition (mentioned above) but also a baseline for effort calculation. A good starting point is construction engineering with “catalogues of material effort”, which are widely used. Construction engineering is slightly older than IT (just 7000 years) and is therefore a good example of best practices.

IT system construction is not just “swinging a shovel” (beautiful sentence by TS), so the final catalogues in IT should be extended at minimum with technology and project methodology context. But, in my opinion – the lack of catalogues and the current unlimited heuristics for the effort calculation is one of the missing parts of science in IT (look at one of my first posts).

Summarising, in a future IT industry, the providers and customers will be rated, exposing their current maturity in conducting IT projects. The scope of the project will be defined on a system level, precisely defining the expected artifacts. And the scope-time-funding balance will be calculated not estimated with the help of “material and human effort catalogues”.

This is to come, construction engineering needed 7000 years to achieve this maturity level, hopefully, IT will get more agile 😊