Initiation #
The beginning of the project is referred to as the commencement phase. In this phase, the project’s idea is explored and developed. This phase’s goal is to see whether the project can really be completed. Choices are made on who will lead the effort, which organization will be participating, and whether the business will get enough support from those involved.
This step requires the existing or future project leader to prepare a proposal outlining the points mentioned above. Business plans and grant applications are examples of this kind of project proposal. The project’s potential sponsors assess the application and give the required funding if it is approved. The project formally starts upon approval. Must be addressed following questions at the beginning phase:
- Why this project?
- Is it physically possible?
- What are the desired outcomes?
- What are the project’s limits (what is included in the project’s scope)?
The capacity to say ‘no’ is a critical characteristic of a project leader. Once individuals get enthused about a project, it tends to grow in scope. ‘While we’re at it, we may as well…’ is the underlying idea. Projects to which additional objectives are added, and projects that continue to grow are almost guaranteed to run late and are unlikely to fulfil their initial aims.
The first step is to establish a connection amongst all of the project’s stakeholders. Unrealistic expectations regarding the project’s outcome may be avoided if the scope is well understood. In order to get started, establish a connection between the various people involved. It is essential to have a firm grasp of its scope.
The method chosen for a specific kind of project has a significant impact on its outcome. For instance, a research and development effort may provide a report assessing an application’s technical viability. A project that results in developing a prototype includes all of the functions of an application. Still, they are not required to be appropriate for usage in a specific environment (e.g., by hundreds of users). A project that produces a functioning product must also address maintenance, documentation, and application administration issues.
Numerous misunderstandings and disputes occur due to the people engaged in project management being unclear on these points. Customers may anticipate a functional product, while project team members believe they are creating a prototype. While a sponsor may think that the project would result in a useful piece of software, team members must first determine if the concept is technically viable.
Definition #
After the accepted initiation project plan, the project started the second phase: the definition phase. This phase specifies as precisely as feasible the requirements connected with a project’s outcome. This phase entails determining the expectations of all parties involved in the project’s development. How many files are required for archiving? Should the metadata be in the Data Documentation Initiative (DDO) format, or would the Dublin Core (DC) suffice? Are files allowed in their original format or only those that adhere to the ‘Preferred Standards’? Is it the depositor’s duty to guarantee that a dataset is properly processed in the archive, or is this the archivist’s responsibility? Which assurances will be provided about the project’s outcome? The list of inquiries might go on indefinitely.
It is critical to establish needs as early as feasible in the process.
Wijnen (2004) establishes the following types of project needs as a memory aid:
- Prerequisites
- Requirements for functionality
- Requirements for functionality
- Design constraints
Preconditions provide the framework in which the project must take place.
Legislation, rules governing working conditions, and approval procedures are all examples. These criteria are immutable inside the project.
It’s important to remember that requirements specifications are those that have to do with the quality of the final output—technical specifications related to how the project’s results will be used. For example, the number of errors must be reduced by 90% after a software project is finished. Design restrictions, on the other hand, are project-specific requirements. Hazardous chemicals and foreign partners with questionable labour standards cannot be included in the project, as an example.
During the defining phase of a project that included building a web application for a consortium of major organizations, no decisions about the browser that the program would support were made. The consortium thought it would be Microsoft Explorer since it was ‘everyone’s browser.
The developers built the application on Firefox because they were already familiar with the browser and had several especially helpful features throughout development. Because most websites designed for Firefox also appear great on Explorer, the change was first imperceptible. However, towards the project’s conclusion, the client started to protest that the website ‘did not look nice.’ The programmers, who were accessing the site through Firefox, were perplexed by the complaint.
When it became apparent that the two browsers were incompatible, programmers responded defensively, ‘Can’t they install Firefox? After all, it is complimentary’. On the other hand, the organizations obligated governmental system administrators who, for whatever reason, refused to install Firefox alongside Explorer.
Even if they wished to install it, the procedure would have been long, and there would have been additional expenses associated with the time spent by the system administrators on the job. Finally, determined that the application would need to adapt for Explorer. This required significantly more effort, which resulted in the project falling farther behind schedule than it already was, necessitating negotiating the additional costs. Later investigation revealed that the various organizations were using disparate versions of Microsoft Explorer.
It is critical that all stakeholders engaged in the project, especially the end-users who will utilize the project’s outcome, participate throughout the defining phase. Because end customers are often not the ones who order the project, they are frequently neglected. During the defining stage, the customer, who pays for the project, is asked to contribute to the requirements. Nonetheless, the initiative gains by inviting future users. As a starting point, it is beneficial to establish convening meetings with all stakeholders throughout the project’s defining phase.
Later on, users (young people) got involved in the development of an educational video game. When the game was almost ready, it decided to test it with a group of young people. Their first evaluations seemed to be moderate and amicable. However, when pushed, they acknowledged that they had found the game ‘very dull’ and would ‘not play it themselves. If these young individuals engaged early in the project, the game would undoubtedly have been a success. Currently, the game is almost unplaced on an Internet website.
The defining phase produces a list of needs from all stakeholders engaged in the project. Each condition, of course, has an inverse.
The more intricate the job, the more time and money will be required. Additionally, some criteria may clash with one another. New copy machines intended to be more environmentally friendly; they must also satisfy fire safety standards. Regulations governing fire safety mandate the use of flame-retardant materials, which are less ecologically friendly. As shown in this image, it must be addressed.
Finally, a list of definite criteria is created and submitted to the project’s decision-makers for approval. After approval of the list, the design process may commence—the majority of agreements between the client and the project team reached by the end of the definition phase.
The requirements list establishes the parameters within which the project must operate.
This list is used to assess the project team. As a result, the client cannot add additional needs after the definition phase.
A computer installation created as part of a project includes a new display at a museum. Due to the absence of a defining phase in the project, no concrete negotiations between the museum and those responsible for the installation’s construction reached. When the installation’s computer failed halfway through, the museum believed the project’s guarantee would cover it. The project team took a contrary position—required Negotiations amongst the directors to reach an agreement.
Design #
The definition phase’s set of requirements may be used to guide design decisions. During the design phase, one or more designs are created that seem to fulfil the project’s objective. The design phase may produce dioramas, drawings, flow charts, site trees, HTML screen designs, prototypes, picture impressions, and UML schemas, depending on the topic of the project. The project leaders use these drawings to choose the final design for the project. Following it comes the development phase. Once a design is selected, it cannot alter throughout the project’s subsequent stages as with the defining phrase.
The phrase ‘design department’ was not appropriate in this instance; rather, it referred to a group of designers who collaborated. Additionally, everyone was far too busy, including the department’s chief.
One project required the creation of a range of designs that were critical to the project’s success. The designs developed by a young designer in the project team. Although the head of the design team was ultimately responsible for the designs, he was never present a project team meetings during which review the designs. The projecting boss consistently invited him and sent him emails with drawings by his young colleague, but the emails went ignored. The project leader and the young designer believed incorrectly that the department head had accepted the designs. The phase of implementation started. When the project was almost complete, delivered the outcome to the department head, who got enraged and ordered that the whole thing can redone.
