Development #
During the development phase, all of the necessary components for implementing the project are assembled. Potential suppliers or subcontractors are contacted, a timetable is created, supplies and tools are ordered, and employees are instructed, among other things. When the implementation phase is ready to begin, the development phase is complete. All issues must be clarified for the people responsible for execution.
A formal development phase is perhaps unnecessary for certain projects, especially smaller ones. What is critical is that it be obvious what must be accomplished during the implementation phase, by whom, and when.
Implementation #
During the implementation phase, the project gains form. This phase entails the actual building of the project’s outcome. Programmers are encoding, designers are creating visual content, contractors are constructing, and the real reorganization occurs. This is the period during which the project becomes apparent to outsiders, who may believe the project has just started. The
The implementation is the ‘doing’ phase, and it is critical to sustaining momentum throughout this period.
In one case, the project team was unaware that one of the essential team members was going to become a parent and would therefore be totally unavailable for about a month. When the time came to replace him, an external expert was called in to prevent the team from grinding to a stop. While the team was able to keep, the external expertise took a significant bite out of the budget.
At the conclusion of the implementation phase, the outcome is compared to the list of requirements established during the definition phase. Additionally, it is assessed in relation to the designs. For instance, testing may be performed to confirm that the online application supports Internet Explorer 5 and Firefox 1.0 and above. It is possible to verify whether the trim on the building was constructed in accordance with the agreement or whether the materials used were actually those specified during the defining phase. This phase is complete when all criteria have been fulfilled, and the resulting product is consistent with the design.
Those participating in a project should bear in mind that it is very rare to obtain a product that exactly satisfies all of the criteria stated during the defining phase. During the course of a project’s execution, unexpected occurrences or advances in understanding may force the project team to depart from the initial set of requirements or other design documents.
This is a possible cause of contention, especially if an external client has placed an order for the project’s outcome. In certain instances, the customer may invoke the agreements reached during the defining process.
Generally, requirements cannot be modified once the defining process is complete. This also applies to designs: once the design process is complete, the design cannot be altered. If this becomes required (as it sometimes happens), the project leader should ensure that the modifications are communicated to all stakeholders (especially decision-makers or consumers) as soon as possible. Additionally, it is critical that the modifications made be properly recorded to avoid future misunderstandings. Additional information on the project’s documentation is included later in this guidebook.
Close Out & Follow Up #
Although critical, the follow-up step is often overlooked. During this phase, all essential arrangements are made to ensure the project’s success. The follow-up phase may include the creation of manuals, instruction and training for users, the establishment of a help desk, the maintenance of the result, the evaluation of the project itself, the writing of the project report, the hosting of a party to celebrate the achievement of the result, the transfer of the project team to the directors, and the dismantling of the project team.
The follow-up phase’s key issue is when and where the project will conclude. Project managers often joke that the first 90% of a project moves fast, and the last 10% may take years.
The project’s boundaries should be evaluated from the start of the project in order for the project to be closed in the follow-up phase once it reaches these limits.
It is sometimes unclear to individuals involved whether the end outcome of the project will be a prototype or a functioning product. This is especially prevalent in creative initiatives with uncertain results. While customers may anticipate receiving a product, the project team may believe it is developing a prototype. Such situations are most apt to emerge during the follow-up period. Consider the example of a software development effort designed to validate a novel idea. There was considerable worry about the feasibility of obtaining any findings at all.
Eventually, the project had positive outcomes. The team produced software that functioned well, at least within the confines of the testing environment. The client, who was unfamiliar with information technology, believed he had gotten a functional product. After all, it had worked on the computer at his office. Although the program functioned well, when it was placed on the PCs of fifty workers, the prototype developed issues and became unstable at points.
Although the programmers could repair the software, they were pressed for time due to their involvement in the next project. Additionally, they had little interest in repairing what they regarded as an experimental item. Several months later, when Microsoft introduced Windows Service Pack 2, the program ceased to operate fully. The client was enraged that the ‘product’ had been discontinued.
