In my experience I have came across projects that were in trouble. I tried to find parallels in those projects to find the early warning signs. In this post I will share 2 of the games you can do to discover if your project is in trouble.
Do the numbers game
Projects going into trouble mostly have problems with the numbers. They either don’t have productivity figures or are not activity measuring the numbers. When there are no figures try to collect a sample and do the calculations. Based on these numbers you can ask the senior consultants if the found figures are normal.
In my experience I found troubled projects taking 4 times more hours to build functionality than normal. Based on these figures it’s wise to assess the reason behind this low productivity. The cost for maintaining this solution would be also 4 times higher. In a BI project I found the reporting part took twice as much time as you normally expect in a BI project. The coding was very manual intensive.
Do the complexity game
Most projects go into trouble because architects and developers are trying to solve all problems with one generic solution or complex solutions. There is nothing wrong with a good generic solution. It goes wrong when generic solution turn into complex solutions that no one understands or is able to maintain.
In the complexity game you simply ask individual team members to explain the solution. If it takes a long time to explain or draw the solution you know your project is in trouble. If team members draw a different picture it’s the same.
In my experience I have seen architect trying to workout an architectural principle. After a long time they were not able to produce a readable document.
In my next post a will share two more games:
– Do the team game
– Do the expectations game
Not surprisingly I came across a linkedin group Troubles Projects – Rescue my project. Look for more ideas in this group. “
