Our team has just ‘finished’ the initial release phase of a multi-year project. We acknowledged each others’ effort in a round of handshakes and smiles, knowing we put in an unusual amount of effort within the past week.
Still, the project did not deliver on all of its goals. Regardless of the circumstances, it left a bittersweetness from not seeing the full implementation in action. No one wanted an incomplete deliverable, yet it happened.
It’s time to chew on what went well and what went wrong – to learn from the experience and to also evaluate the points from process and cost perspectives.
What went well:
- Cohesive teamwork
- Focus on the deliverables
- Selecting appropriate technologies to use
- Willingness to go the extra mile
- Getting the needed support from management
Yet there are also what went wrong:
- ‘Pockets’ of project information, where only a few people know the critical data/logic
- Insufficient time to completion
- Getting critical data at the last minute
- Changes in solution approach, late in the project
Commitment from development team members definitely shined through the entire process, no one doubts that.
Process and Cost Analysis
One approach is to see how much technical and other debts we have on the project, then estimate the amount of effort required to reduce the debts.
Technical Debt
I am finding that there is quite a bit of technical debt on multiple fronts:
- Bugs in the UI Event-handler process(es), that are contributing to data interchanges at unintended points in the process. (May have to do with various IoC done using Unity Application Block).
- Instead of minimal message package, the service-consuming application is invoking a service with an entire object, serialized in XML (already too verbose).
- Data persisted with MongoDB also houses unnecessary data.
- Data retrieval takes too long.
- Logic applied in retrieving data is not finalized.
Documentation Debt
- Reasons behind some of the mid-project changes in solution approach
- Service APIs are not ReSTful yet, and API documentation is lacking
- UI/Event + Unity process documentation is lacking
All this debt, on both technical and documentation aspects – it makes me wonder how the project was deemed successful by project management.
Among the documentation debts, not knowing the reasons behind some of the solution approach changes is a very cumbersome item. While not having documentation can always be a cumbersome item, this is in regards to the real ‘reasons’ behind the changes – therefore this situation is usually more problematic than something like a missing API documentation, for example. Developers, in general, do not have to concern themselves over the business reasons most of the time, but project management definitely does. If the reasons were technical in nature, or involved technical input, then the developers should also be aware of the reasons, to a reasonable extent.
offthemesh 