The Project Implementation Phase is the last phase of the project. At this stage, the business would have provided their formal acceptance of the User Acceptance Testing.

In the Project Implementation Phase or the Project Release Phase, the project team conducts the Implementation activities to successfully introduce the changes into production. After the project release, the business users are required to do a final Post Implementation Validation.

The project manager would now conducted a Post Implementation Project Review to discuss the project learning, gather stakeholder feedback to establish areas where the project team were effective and those where the team could have performed better. This Review meetings also marks the closure of the project – although the project team might remain passively engaged on the project till the completion of the Warranty Period (usually 60-90 days post the implementation)

Towards the end of the Project Release Phase, the project teams are disengaged from the project.

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page.

The Project Testing Phase follows the Project Development Phase. The Project Testing phase focuses on the test execution of the System Execution Testing and the User Acceptance Testing.

The System Integration Testing (SIT) tests the integration of the different systems to establish effective compatibility between the systems. Usually systems or applications have 3 layers – Application, Database and Integration Layer.  The Integration Layer ensures correct connectivity between the Application and the Database. The SIT focuses on the Application and Database test conditions with greater emphasis on the Integration Layer to ensure that the data is passing through successfully between the two layers. Additionally, the Test Managers and Test Analysts would be ensuring that the data is being saved correctly on the database, and the data is being rendered on the application level too, i.e., correctly on the User Interfaces.  Overall the testing should ensure that the project team has successfully met the business requirements.

The Technical Team conducts the SIT and the business team is not actively involved.

The second stage of the phase is the User Acceptance Testing (UAT), which is to establish that the business users are ready to accept that the development of the project meets their needs. The business users conduct the UAT, however the technical team remain involved at this stage. At the end of this phase, the business users provide their acceptance or approval to promote the code to the Production Environment.

Other types of testing including Stress Testing, Regression Testing or Volume Testing can be conducted during this phase of the project.

Please note, all the testing is conducted in the test environments using test data. The UAT is usually conducted in ‘production like’ environment in the test region.

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page. 

The Project Development Phase follows the Project Architecture and Design Phase. At this stage, the detailed design and the test conditions would have been finalised, published and signed off by the relevant stakeholders. The Project Development Phase focuses on the actual coding of the solution.

The technical developers of the team would now use the Detailed Design document and other related documents to progress on the development activity. This phase, developmental activity could be divided into two phases. The first is the actual technical development of the solution; the second would be the testing that is executed by the development team to ensure that the coding is producing the expected results. The testing is also called Unit/ Assembly or Component Testing, and should not be confused with the System Integration Testing  (SIT) or the User Acceptance Testing (UAT) – those tests are conducted in the subsequent project phase.

The unit testing is conducted in a limited environment and might run the risk of being tested in a limited capacity. This is because development activities are usually executed in an isolated environment and the complete end-to-end testing might not be possible. This test is to prove that the individual team’s development activity is producing the expected test results. The unit and assembly testing is a very good practice and the output of the test execution is passed on to the project test team to conduct the tests required in the subsequent phases.

The testing team at this stage, in parallel to the development activity and the unit testing, prepares for the SIT and UAT tests. This involves creation of a Detailed Test Plan, which is a day-by-day plan of the sequence in which the test conditions would get executed, and ensuring that the test environment is ready for the execution of the SIT and UAT. The testing team would also assist in ensuring that the Unit tests are executed and documented by the development team.

At the end of the phase, the code specifics and the test related documentation, including any changes to the SIT and UAT test conditions and the test plan, are reviewed and approved by the stakeholder for the project.

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page. 

The Project Architecture and Design Phase involve designing the technical solution for the project. At this stage of the project, there should be an approved Project Charter and Requirement Report to support the design of the project. The Application Architects and Technical Leads of the project lead this phase of the project.

The technical resources of the project would now design each technical requirement based on the information already captured in the Project Analyse Phase. Their detailed design would need to consider the changes being proposed to all the impacted application, architecture and infrastructure and address the security requirements of the project. At this stage, involvement of the business stakeholder would have reduced considerably – as the technical architects rely on the technical requirements which could be further traced back to the business needs documented by the business stakeholders.

The output at the end of this stage would be the Design Documents, which are usually reviewed internally by the technical teams and their stakeholders. The business is usually not requested to approve the Technical Design Documents.

In parallel to the Design activities of the project, the testing team progresses with the finalisation of the testing requirements. At this stage, the Test Manager documents the Test Conditions for the Systems Integration Testing, which is executed by the technical project team. The business representative would also be documenting the test conditions for the User Acceptance Testing, which would be executed by the business users. Interesting to note, that while the System Integration Test Conditions would be documented using the Technical requirements, the User Acceptance Test Conditions would be using the Business Needs. Overall there should be synergy between the two sets of Test Conditions as the Technical Requirements were based upon the Business Needs. They are, and along with the Test Strategy are documented in the Test Report.

At the end of the Project Architecture and Design Phase, the Design Documents and the Test Conditions should be approved by the relevant stakeholders in order for the project team to progress to the subsequent phase.  As stated earlier, while Design Documents are approved by the technology stakeholder, the Test Report would need to be reviewed and approved by business and technology stakeholders.

The Design Specifications could be traceable to the technical requirements, which could be traced back to the business needs.

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page. 

The Project Analysis Phase follows after the end of the Project Initiation Phase. At the start of the phase the project team would have an approved Project Charter that would document, amongst other critical items, the Business Needs, the Project Objectives and the Project Scope. The objective of this phase is to translate the business needs into technical requirements. In this phase the business needs are broken down into business requirements with the objective of understanding each business need in great detail, establishing linkages with internal or external systems and thereby documenting technical requirements.

The Business Architect and / or the Analyst lead the Project Analysis Phase. She would need to engage in multiple discussions and conversations with the business stakeholders to establish “What Does the Business Want”! This is where the stakeholders are probed to differentiate their Wants from the Needs (as documented in the Business Needs) This assists the Business Analyst to clearly document the Business and Technical Requirements. This also helps in understanding the ‘Change’ that the project proposes to introduce – a clear comparison between the current state and the future state is usually a critical outcome at this stage. Please note, even at this stage, the project team shouldn’t be analysing the solution to the problem – they need to focus on understanding the problem. A miss at this stage could prove costly towards the latter phases of the project. A single business need could have multiple business and technical requirement to meet that need. This stage is at times also called the Business Analysis Stage.

Once the business requirements are clearly documented as part of the Business Analysis Stage, the Technical Analysis is initiated. As part of the Technical Analysis, the Application Architects and Technical Leads become fully engaged in the critical activities of the project. It is they who now understand the technical requirements and establish the technical systems that would potentially get impacted. They, along with the Business Analysts, understand the technical impacts, and documents how each of the technical requirements would be met. The technical requirement, along with the current and future states of each of the requirement (or of all the requirements together), the technical changes and the technical systems impacted are all documented in the Project Requirement Report.

While the Business Analysts get engaged on the Requirement Elicitation process during the Business and Technical Analysis stages, the Test Manager also gets actively involved in the project. They are responsible for elucidating the Testing Strategy of the project. They Analysis each of the business and technical requirements and establish the testing needs. The testing need would involve understanding measure of success of testing each of the testable requirements. At this stage, it would be useful for the testing team to get involved in documenting the Test Conditions and Cases. The test conditions are events in the testing cycle that would need to be executed to test each of the technical requirements. There could be multiple test conditions against a single technical requirement.

At the end of the Project Analysis Phase, the stakeholders should be aligned and would have provided their approval to the Project Requirement Report and the Test Strategy documents.

Interesting to note that at the end of this phase, there should be a clear traceability between the Business Needs and Technical Requirements, and the Test Conditions (if prepared at this stage).

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page. 

The Project Initiation Phase is the phase where the project team is formed and the project is formally ‘kicked-off’.  This phase can also be called a ‘Define’ Phase.

Usually at the start of this phase the project team might consist of very few team members, while at towards the end of this phase the team ramps up and forms the project team. It is understood that just before the start of this phase the project stakeholders would have realized the need of initiating a project in order to resolve a problem or to realize a potential opportunity.

At the start of the Project Initiation Phase, the stakeholders would document the project problem or opportunity statement (also called a Business Case). The Business Case would then be passed on to the Program Manager and the Resource Manager.

The Program Manager would work together with the Resource Manager initiate the formation of the core project team – the Project Manager would be identified at this stage of the process (if not already assigned on the project earlier in the phase).  The Project Manager along with the other assigned key resource would then schedule a Business Case Review meeting with the stakeholders of the project. The Business Case Review meeting would give an opportunity to the core Project Team members to understand the business needs and requirements ( in addition to the business problme/ opportunity statement) and to obtain alignment on the scope of the project (and dependent on the nature of the project, what would be outside the scope of the project).  The Project Manager and the other core team members would then start creating the Project Charter, using the information gathered from the Business Case and the discussion items from the Review Meeting. At the same time, the team would then start engaging the other specialist resources to form the extended project team.

High Level Estimation forms a very important aspect of this phase. The project team would estimate a ballpark costs and schedule estimate which is usually communicated to the stakeholders and is also addressed in the Project Charter.

The Project Manager is also responsible to ensure that the Project Execution Strategy or plan is aligned with the core project team and the stakeholders. The Project Execution Strategy documents (amongst other key items) the project team structure, the roles and responsibilities of each of the key players in the project, the communication plan, the change management strategy and the documents that would be published at the end of each phase.

The Project Charter along with other relevant documents is published for stakeholder approval, and an approved Charter is considered a key output at this stage for the project to move into the subsequent development phase.

Project Managers need to be cautious in that in this phase project teams tend to get all consumed in analyzing a solution to the project problem, which usually ends up in a long delayed Project Initiation Stage. The Project Initiation Phase usually attempts to elicit the ‘WHAT’ and not the ‘HOW’, so understanding the scope of the project is crucial at this stage, and not necessarily the solution.

For for more information Project Charter and Business Case, recommend you read this article, Project Charter and Project Business Case.

To the readers: If you have enjoyed reading the article, please could you ‘Like’ us on our Facebook page at PROJMENTING – FACEBOOK, thank you. Also if you like to subscribe to the blogs via email, please add your email address and click on Subscribe on the right hand panel of the page.