Observed from Implementations: SDLC Iterations & Tuckman
From the Tata Consultancy survey (2007):
“62% of organizations experienced IT projects that failure to meet their schedules”
From the Robbins-Gioia Survey (2001):
“51% viewed their ERP implementation as unsuccessful”
With complexity of large IT/ERP systems implementation, various misunderstanding & miscommunications are unavoidable … This disrupts the SDLC model by making each phase to be revisited at many points of the project. This usually generate unaccounted delays to the project, which could cause the result you see in quotes above.
After going through several module implementation, I have seen a pattern. After the 1st code delivery … there is almost a guarantee a massive change request or redesign document. After that is done, the regular defect appears for fixes.
The traditional waterfall model and most major project planning expects people get the solution right in one shot. But of course this never really happens, it takes several tries developing & refining to get to an acceptable solution. That’s why many all IT project ends up different from the original requirement.
From observation, it seems it naturally goes into a few core iteration of code implementation before the solution is ready to go-live.
After studying project management & learning about Tuckman’s stages of team development. I notice that developing an IT solution from start to go-live ready is similar to a team going from forming to working productively. Although each iteration seems to go through a simplified version of SDLC. (Feasibility, Analysis, Design, Implementation, Testing)
This is where the client defines the requirements & specification is developed & signed off. This phase end when the first code delivery for the requirement is tested.
When this occurs, the client finds there is a mismatch between what they imagine and what is delivered. This part involves the redesign/massive change request to get the solution functioning per the client’s business needs.
This is when both the vendor & the client understand what the client needs, both are polishing the system/solution to a stable state.
This part can only be archive when the solution is actually performing, through post go-live period.
In all of these phases, QA & programmers are needed for on going development & validation before the solution is usable for the client.
Unless you a building a off-shelf solution with zero customization, project planning would go off track. Instead of viewing a IT implementation as one long SDLC, plan better by anticipating mismatch in spec & refinement in deliverable.
Next few posts, we will go in depth of the phases.