Phase 5 – Build & Development 

– The build phase of the project is the one phase whereby the project manager has little involvement in

– At this stage the project manager should make sure the requirements & design phases are completed and in order

– The build team will carry out a review of the requirements and plan for the build ahead 

– If run in an agile fashion the build will comprise of SPRINTS, these normally last 2 weeks each and depending on the project or form of agile used 4 or 6 SPRINTS should be enough to complete the build

– The project manager should keep in regular contact with the build team during this phase 

– This can be via weekly updates or / and daily stand ups

– The stand ups during the build phase if agile should be run by a member of the development team with the project manager attending and checking the status of the requirements being built and if any issues have arisen

– Kanban boards in JIRA are very useful for managing and tracking status of the SPRINTS during this phase

– The build team should report back weekly on what has been completed and what is left in the current SPRINT

– If agreed with the project manager and end user team built requirements should be released to the core project team for testing 

– This should only happen once the development team have performed and signed off on their system testing 

– Once a SPRINT is finished the development team will sign off on this and move to planning the next SPRINT.

– SPRINT retrospectives should happen just to make sure any issues are captured and remedied before the next SPRINT commences

– For other methodologies specifically Waterfall the build phase can take longer and tends not to run in SPRINTS as this would not work.

– The project will normally be larger in size and more complex

– Agile build suits small to medium sized projects and standard builds

– When bespoke and customer specific requirements outside the normal scope of a system are needed then build will take longer and the project manager must plan this accordingly 

– For Agile build development teams tend to be centralised and will work off very rigid planning schedules

– For non agile specialist developers may be needed and their time will have be managed as part of a project managers resourcing plan

– While testing can take place during the build phase notably some system testing the bulk of testing will take place when build finishes and project transitions to the testing phase

Phase 6 – Testing (all types) & Training 

Testing will be explored in detail in a separate future blog as part of the core skills series. Below is an overview at a high level of the different types of testing available and most common uses in project delivery.

• Static testing – this is making sure the design matches and includes all the signed off requirements. Static testing is normally executed by a dedicated testing team or testing manager. It can also be performed by project managers, business analysts and a solution design team.

• Unit testing – this is making sure the build includes all the design (of requirements) that were included as part of the design phase and also in the design document (if one exists). 

Unit testing is normally executed by a dedicated testing team or testing manager. It can also be performed by project managers, business analysts, solution design team and solutions architects.

• System testing – this is making sure the completed build performs as expected and matches the design of the requirements. The difference between unit and system testing is that system testing is testing the built functionality as opposed to making sure what was written down in the design document has been built. System testing is normally undertaken by the development team or a separate designated testing team if available. It is helpful if the testers are provided with acceptance criteria to evaluate their testing against and to assign a pass or fail based on this. The acceptance criteria should be created by the project manager and core business team (system end users) and or a testing manager if available.

• System Integration Testing (SIT) – This involves the testing of all sub systems and components of the overall complete primary system. It should be completed when all system components are ready to be tested and should be executed in a sequential and logical way. It can include testing of hardware and software. It is similar to end to end testing as it’s aim is to make sure all processes in the chain that involve individual systems work as they should and as set out in the acceptance criteria. For example if data needs to be transferred from one system to another in xml format, then the necessary integration tests should be able to prove that this can happen and the test should pass or fail accordingly.

• User Acceptance Testing (UAT) – UAT should happen when all the above testing types are complete and any bugs and issues have been rectified. UAT is for the system users to make sure that the system works as per the signed off requirements and design. The system (end) users should create in tandem with the project manager test cases and scripts within the cases for the UAT cycle. If a testing manager is a available then he/she would do this. Specific acceptance criteria should be created to use as the benchmark to pass or fail each test script. UAT can involve numerous system users and it can take some time to execute depending on the size of the system(s) being implemented. The project manager should manage this with system users and be conscious that the UAT is executed in parallel to BAU work so planning of UAT is critical to project success. Only when all tests have passed with all bugs and issues resolved to the desired satisfaction of the system users should UAT be signed off. Once this happens the deployment phase can begin.

Other testing types can include End to End and Penetration testing & these will be explored further in the testing blog.

Phase 7 – Deployment 

When all the necessary testing types have been executed and signed off deploying the system is the next step. But this needs plannng. The two common types of deployments are phased and Big Bang. Phased is when the existing system will run in full or part alongside the new system until a full deployment. Big Bang is switching the old system off and releasing the new system to end users. This carries more risk as the back up of an old legacy system is not there but the cost of running one system instead of two should alleviate the risk in part.

The day of the release has to be planned and communicated with the wider business and most importantly all the areas affected. If system downtime is needed before release this needs to be communicated to all the users affected whether internal or customer based.

The project manager should control and manage the planned release in tandem with the technical IT team who will initiate deployment. All tasks for the release should be noted in a run book and agreed as walked through with all the necessary stakeholders at least a day before if not earlier. The more time you give yourself the more time you have to rectify any issues noted. In my experience deployments happen outside core business hours, so either in the evening from 6pm to 10pm for example or if more time is needed than the weekend is more appropriate. This is done so that the impact on BAU is minimal, especially if your business is customer driven.

Once you are happy the planning of the deployment is complete and all stakeholders needed are ready then deployment can proceed.

The run book flow can be managed jointly by the project manager and technical team during the release until all tasks are completed and signed off as working. You will need some testers to test certain tasks and functionality are working as expected once deployed. Once all tasks in the run book are deployed and tested then deployment can be signed off and the system should now be ready for use.

This leads on to hypercare (support) and issue management.

Phase 8 – Support / Hypercare 

Once the system is up and running and fully deployed issue management becomes key. No matter how much testing was completed prior to release issues and unforeseen bugs and functionality problems do arise. All issues need to be noted in an issues log and managed appropriately until resolved to the satisfaction of the end users.

The process for managing issues can be different for internal releases and vendor managed systems. Also whether you have deployed in a Big Bang or Phased approach will affect your issues management.

For example if you have a legacy system to fall back on you may be able to take the decision to switch the new system off whilst issues are being investigated and worked on. Alternatively if possible you may decide to keep the new system enabled for all the working functionality.

For Phased deliveries the luxury of having a legacy system is not available and rectifying issues becomes paramount as the effect on BAU can be critical especially if working in a customer facing business.

If it is an internally managed system that has been deployed managing the issues may be easier as the technical team could be in house.

However if the technicians are external , either because of outsourcing or because of a vendor driven deployment then managing issues resolution can be trickier and this is where communication is key. The project manager must be forefront in managing the communication and updating all effected stakeholders.

Phase 9 – Project Closure

So the system is live and the project is deemed a success or the project has been shelved due to costs being exhausted, whatever the position is the project has to be officially closed. This can be a lot harder than you think. The reasons being can include 

• a natural drift away from project calls & work so stakeholders conclude the project has finished. 

• Closure may not be a formal part of the project structure. 

• Stakeholders are now too busy with other work 

It is up to the project manager to manage the closure phase. Meetings should be set up to officially sign off on closure & move from project to BAU. This will free up the project manager to work on other projects and be allocated more work.

A retrospective known as a lesson learned document should be created. This should outline the areas that caused issues during the project and should be used as a guide to improve ways of working and future project delivery. However from my experience it can be difficult to get stakeholders to commit to (1) Attending a lessons learned session to discuss the findings (2) If they do attend getting stakeholders to admit perceived failures or areas for improvement and then acting on them or committing to improve areas of weakness in project structure and delivery.

The project manager should endeavour to draft the lessons learned document and ask for feedback and update accordingly once received. It should be then shared with the project stakeholders. There will be occasions when some tailoring of the document will be needed to maintain good vendor or client relationships. No party likes to be criticised and if some information is deemed inappropriate or sensitive then remove.

The project manager should always get approval to send the document out to stakeholders and be conscious of who is on the distribution list.

Once the project has been officially signed off BAU officially starts and the next project cycle can begin.

But do toast success if the project has been deemed such and if unfortunately the project has been deemed a failure, learn from this as any failure can produce valuable knowledge which can be used in future project deliverables.