Project Close-Out – Part 1

With the system is successfully commissioned, it is time to close-out the project. Just as there should be a defined process to kick-off a project, there should be a define process to close a project. Consider developing a check list (just like project kick-off) that must be done.

The Obvious

 First and foremost, your project close-out should include adequate steps to make sure all project information and materials have been properly stored for future reference. This should include procedures to incorporate any field changes made during the commissioning, so that the final project information accurately reflects the final deployed solution.

Engineering perspective

 Alliance Partners will commonly require some sort of project review. At a minimum, it is a chance to review lessons learned and share them with the rest of the staff. More importantly, it is an opportunity to capture IP. What can be reused for future projects including software architecture, hardware designs, even methodologies and techniques? You should also have procedures to ensure that all project documentation is completed and properly stored.

Next week, we’ll cover the commercial aspects of project close-out.

Project Commissioning – Part 2

In the first part of Project commissioning, we talked about final testing and preparation of the project including the actual shipping of the system. This, week we talk about the on-site commissioning.

Delivery and Installation

Since we completed the FAT, system delivery and installation is always a breeze. Right?  Well, just in case, you should have defined practices for field changes. What is acceptable? Anything that makes the system work? Gets the customer off your back, so you can get out of there? I guess whatever you decide is acceptable, but there should be a method to document the field changes and make sure that all project information is updated accordingly.

SAT Down with Your Customer

After the installation is complete, you should again have a process to validate its operation against the specified requirements. This time for sure, you should have a document validating customer approval before you leave the premises.

License to Drive

You should also have a process by which you clearly transfer all software licenses to your customer. Note that is not sufficient has just taken possession of the system. You should inform them that you are transferring the licenses and some way for them to accept the terms and conditions of those licenses. For instance, they have to break the shrink-wrap, an envelope, or container that contains the associated licenses.

Project Commissioning – Part 1

OK, so you are getting close to the finish line – almost done with your project development. You may running on schedule or rushing to meet the deadline, but it is still no time to let lack of project management lead to unnecessary and costly mistakes.

FAT and Happy

Make sure that you perform a thorough Factory Acceptance Test (FAT) as defined by your V-diagram process to validate that your system meets all of the specified requirements. Involve the customer if possible. But, regardless, there should be a formal sign-off sheet with initials by each met specification. Some Alliance Partners even have a formal approval process before the system can be shipped.

In Ship Shape?

While being FAT is good, you still want to be in ship shape. So, take steps to avoid errors and delays. Have you checked to see if your labeling meets any requirements that your customer must have? Do you have a way to verify the complete shipment (e.g. pack slips)? Do you have insurance guidelines for shipments?

Project Development – Stay on Task

Now that you have an optimal design, the development work can proceed. Your development team should have defined processes and structured approaches to ensure that the work is as consistent and efficient – and conducted according to your project plan. Each development task (sometimes referred to as a work package) should have defined milestones, gates, and deliverables.

Use Standards and Assets

For most service-oriented business, design re-use is the only way to ‘get ahead of the game.’ Re-inventing the wheel – just won’t cut it. So, develop and use templates, coding practices, wiring standards, ….

Test Early and Often

Just like in the manufacturing lines where many NI-based solutions are deployed, it is good to test early and often to catch mistakes early and avoid lots of re-work. So, formalize your practices to test at the unit/module level as well as points of sub-unit integration. Verify that each task is correct and complete. As development progress, check to make sure that the system requirements are being met.

Managing Subcontractors

If you use subcontractors to assist your development efforts, implement processes to make sure that their quality meets your own. That starts with a formal evaluation and selection process, including contracts to avoid conflicts of interest, protects IP, and preserves T&Cs of your work. Once chosen, they should follow your procedures for communications, change orders/authorization, and work approval.

Project Development – Start With a Good Design

Once you’ve taken adequate time to plan and schedule your project, now comes the easy part – the actual project work. But, you may not want to your development team that they’ve got the easy part.

Project Design

Before putting your head down and burying yourself into the project work, you want to make sure that you have an optimal design. What is the best approach to tackling the project? What is the best general architecture for the system? Are their assets (e.g. reference designs, prior work) that can be utilized? Often, a more senior developer can serve as a mentor to help determine the best approach.

Formal Design Review

Once you have selected a conceptual design vet it out against the project scope and requirements. Does it meet each of the design requirements and acceptance requirements? Your assessment should include if the design is overkill for the projects. Can the requirements be met with a more efficient design? Take the time to have a formal design review with non-team members.

Testing the Design

Even after agreeing to the design, you can still minimize your risk by testing the design. For instance, mock up prototypes of key aspects to the project. Mock up all of the HMIs, required reports, …. Then, sit down with the customer to review the design. Some integrators require customer sign-off before proceeding further with the development.