The insufficient maturity of software engineering is materialized in unsuccessful IT projects.
Depending upon the source (Gartner, Standish, other), currently only 20-30 % of IT projects end within the required time, scope, and funding. The rest is either: delayed, re-financed, or reworked.
There is a lot of analysis on the web, describing in detail all the possible circumstances of the IT projects which are either failed or endangered. According to https://www.projectsmart.co.uk/most-it-projects-fail-will-yours.php, there are 32 separate reasons, which can cause it project to fail. There are probably even more.
Theoretically, in trying to avoid failure, we could continuously measure the project against these 32 reasons and control it during the entire project’s lifetime. We would obtain a “project health spectral picture’. Such a picture would be complex, and heavy to understand (humans rarely imagine 32-dimensional space 😊).
Having similar problems visualizing n-dimensional space, I personally manage this problem by generalization. According to my experience, there are only a few domains where the problems can occur:
- Ability of the organization to conduct a project
- Scope definition
- Ability of the provider to deliver
- Scope-time- funding balance
- Determination to complete
Ad a. Ability of the organization to conduct a project means all activities and organizational efforts which are necessary to start and complete a project within an organization.
When the organization is not able to conduct a project we may observe for example:
- Delays in the decision process (i.e. when the PM is not properly empowered),
- Delays in execution of customer’s duties (or deliverables)
- Continuously changing project team members or managers
- Behavioral self-defense of the project team members like denial (sometimes called: “amnesia”) or displacement (recorded as aggression against the provider)
Ad b. Scope definition is the ability of the customer to define and keep stable the project requirements, which are clear and doable. Also the ability of the provider to identify the requirements, to document and manage the change.
When there are problems to define the project’s scope, we may observe for example:
- Delays in the project analysis phase.
- Continuous changes in analysis documentation
- Frustrated analysis team (“lost child” symptoms)
- Poor quality of the requirements documentation like “it ought to be good” or “it should meet popular standards”
Ad c. Ability of the provider to deliver consists of competency power, resources capacity and alignment, and organizational adaptations enabling successful project execution.
If there is no ability, we may observe for example:
- Delays in the design and construction phase with slowing down tendency, or
- Divergent hyperactivity of the designers and constructors, which is either observed like a:
- “Brownian movements”, which means, the solution is changing frequently in every possible way, or
- ‘side to side running, when the solution oscillates between two options
- The urgent need for third-party providers in the middle of the construction phase
- Poor quality of deliverables
The original expression of “side-to-side running” is related to the sail ship stability check, when the entire crew ran from the side of the ship to another, to check the inclination to capsize. I would recommend the vasa sail ship history https://www.vasamuseet.se for more information.
BTW. The Vasa disaster was the origin of “Vasa syndrome”, which can be applied to IT as well.
This may be a subject for an extra post.
Ad c. If the Scope-time-funding balance is not present the IT project turns out to be a “sorcerer’s spell”
Unbalanced projects occur, where the funding, scope, or schedule were either wrongly set, or arbitrarily imposed by a powerful entity (a sorcerer). There is no correspondence with the technical doability of the project regarding available resources, technology, or organization. Typically, there is no practical chance to fulfill all the requirements of the project, but everybody is afraid of the sorcerer telling the truth.
The spelled IT projects can be realized for a very long time – some of them until the end.
But unfortunately, the magic time is over and there is no more magic in IT (here is art in IT but no more magic 😊). IT is an engineering domain – immature and insufficient formalized but anyway engineering. The spelled IT projects are seldom successful, they usually crash with reality when they are not unspelled before the deadline.
We identify unbalanced projects when for example:
- the construction team is overbusy and the solution has poor quality (assuming they have competencies) or
- the construction team is going formal, investing in documentation instead of the solution, or
- there is a big rotation or absence in the construction team
Dealing with spelled projects is problematic and maybe it is a good subject of a separate post.
Ad d. Determination to complete is a common motivation (of the buyer’s organization and the provider) to complete the project.
If the determination to complete is missing we can observe for example:
- undefined or poorly defined project objectives (deliverables within a timeline),
- problems to identify the real project state
- resistance in the project team to change anything in the project
I personally call it a “happy sailing” project but sometimes it is also called “chasing a rabbit”.
The happy sailing can be caused by the insufficient motivation of the project team to complete the project. But It can be also caused by the frustration of the project team, because of problems in other domains. The real reason for happy sailing needs some investigation.
So thinking back about the future of IT, we may imagine, the problems described above will be addressed, and some techniques and procedures will be developed to formalize, estimate and control the IT projects in order to minimize problems.
I will try to describe it in next post.