Storming through System Implementation
After the first functioning code delivery arrives in a system implementation, the client finds a mismatches from what they got and what they are looking for due to miscommunications & various assumptions. (As we have discussed in the Tuckman’s forming phase)
With so many differences between the delivery and the customer expectations, the team eventually figures out, they need a few large change requests to open up requirements & system’s capabilities. Thus, the project team will need to collaborate to derived process & functions that fit both the client’s needs & the system.
To succeed into the implementation, this step is an necessity to refine the system to fit the key business needs. Due to limitation of the interface/API, existing limits/functionalities of other systems or just plain regulations; it does take more effort by the team to define the appropriate changes.
Without carefully monitoring the type of changes being made, the scope can easily get out of control leading to project failure. Hence formal packages of change requests are needed to be signed-off to prevent scope creeps out of hand.
“The team addresses issues such as what problems they are really supposed to solve … Team members open up to each other and confront each other’s ideas and perspectives … The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict.”
If we equate the conflict in a team as changes in a system implementation, we will find many similarities a team development process and the implement projects’s lifecycle.
• Different people in a team with different perspectives & priorities.
• The team have various difference that leads to discussion & conflicts.
• The storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict.
• Without tolerance & collaboration the team will fail
• Different teams in the project with different perspective & priorities.
• The implementation have various differences in functionality & expectation that lead to require changes.
• This phase is necessary to refine the system to fit the key business needs. Changes will be needed due to limitation of the interface/API, existing limits/functionalities of other systems or just new regulations.
• Without understanding what are needed & what the system can be configured to do, the project & system will go out of scope and fail.
Just like the progression during this period, the planned expectations & actual results are similar between a growth in teams and projects. Most team growth, this part is underestimated or even missed by management during planning. Although output of the team relies on how well the conflict is managed & utilized. This is the same in system implementation projects, the project plan would complete correctness in the requirement & specification process, which underestimate this correction piece of the implementation piece of the project. Although the output of this piece is critical on how well the system will adapt to business needs & future processes.
By the end of this phase, deliverable/system has bugs & defect left … the overall system functionality would fit the client’s business needs. The project is near the original project deadline due to the unexpected difference & delays, although the progress of the system is similar to end of development phase in SDLC. There is still a long way to go, which is why most IT project doesn’t meet their deadline is because this phase of work is missed in early planning.