There are many tools and techniques when talking about project management, but the KNXPM-21 methodology focuses on the most important ones to successfully accomplish a small-medium size project:
The advantage of using a methodology is that teams (or individuals) can streamline their work over the projects, being able to measure key performance indicators that are standard across the projects of similar size, and thus being able to quantify overall performance. The matrix above contains the tools and techniques for a minimum viable system integration project management (like the minimum viable product concept), that can be used by non-professional project managers without losing sight of the main activity (system integration). Let´s go one by one to identify the application of each one within the project:
Project Initiation Document (PID)
The Project Initiation Document is a very important piece of the puzzle, as it gathers the most important information acquired at the beginning of the project, during the Initiating phase. A good PID should be comprehensive, including information such as:
- Project definition.
- Starting and end dates.
- Project scope.
- Tracking description (deliverables).
- Organization chart.
This document sets the foundations to work on the quotation, and it outlines the most important features of the project in one single place. The PID is also an important piece in the communication with the client, because it shows that the system integrator has carried out a big effort understanding the needs of the client and aligning them with all the variables that affects the project. The PID is achieved by means of meeting the client with the right set of questions about the project, together with the ability to reflect critically on the conditions around the project.
The quotation is probably the most critical item produced by a KNX Partner. Simply, because a bad quotation can ruin all the effort (poor ROI) or can make him/her less competitive. The quotation is also important because it is the item required to finally authorize the project and move to the next phase (Planning). As previously explained, and given that in most cases it is considered a Firmed Fix Price project, the quotation must be accurate enough to contain all the equipment and installation material as well as the labour hours required to accomplish the project, and it must be achieved without designing the project in full, therein lies the problem! The sub-technique to do this is called Bottom-Up approach. Do not look at the project from the global perspective, but as isolated items. The easiest is, probably, looking at the project as a sum of common infrastructure plus subsystems (e.g. HVAC, lighting) required to fulfil the scope. The cooperation with the other installers/technicians (also considered stakeholders) in the project to achieve this is vital, since the other systems in the project determine the equipment necessary to carry out the KNX project.
KNX Partners must collect data from the other stakeholders, such as type of HVAC system, lighting fixtures, electrical drawings… before the quotation can be specified. With that information as input, together with the scope of the project described in the PID, it is possible creating a comprehensive quotation. Each item of the Bottom-Up approach will consist of equipment plus labour.
The tricky part for untried KNX Partners is to determine the right number of hours for each labour section. That´s one of the advantages of applying project management: the more projects that are tracked, the more data is available to use as a reference for future projects. If you have no previous experience with a task, then you need to work based on estimations. In this case it is advisable that the units are not very long (i.e. items with more than 10 hours), because a poor estimation can lead to deviations of several hours. Another trick for inexperienced KNX Partners consists of running tests at testbenches, and measure the time required to:
- Program 1 channel dimmer unit.
- Wire 4 outputs switching actuator.
- Install 10 din rail modules in a distribution board.
- Connect TP cable to a terminal connector.
- Install a flush-mounted binary input inside a junction box.
The more references, the better. These references can be used for future projects when no references exist.
For better traceability, and to better allow indexing information across the different documentation, it is a good practice to have a labour coding system, which helps to recognize the type of labour at a glance. For example:
Work Breakdown Structure (WBS)
This technique consists of breaking down the project into manageable pieces or components. The WBS contains the total scope of the project, and it organizes the work necessary to be carried out. In a nutshell, the WBS describes the tasks that are necessary to get the job done, how these tasks are grouped and what´s most important, what labour and equipment is related to each task (which determines the budget for each item). The quotation is already a good starting point to create the WBS, although the quotation does not provide any flowchart. For small and medium projects, the following list of tasks and their dependencies can be used. It goes without saying that there is not a “one size fits all”, that´s literally impossible, and that´s why project management exists. Yet there are certain similarities in most projects that allow creating a list of tasks that can cover the WBS, independently of the products or scope of the project. More experienced KNX Partners might prefer creating a more specific list of tasks for each project, but this is for sure more time-consuming and it requires loads of practical experience.
Critical Path Method (CPM)
This tool offers an excellent overview of the project and how tasks depend on each other. It is very natural to look at items as isolated tasks, but the truth is that many tasks depend on previous tasks (as indicated in the “Basic Concepts”, the most common dependency is finish-to-start). Using the WBS as input, and adding a layer of information (start and finish dates for each task and their dependencies), the outcome is a calendar-based map of the project, where the critical path can be found (list of tasks that do not admit delay). Please refer to the “Basic Concepts” chapter for more information, including a practical exercise.
Earned Value Method (EVM)
This tool, as explained in detail in the “Basic Concepts” chapter, is ideal to track the performance of any project. Furthermore, it provides real time parameters that allows the user to adjust the progress and forecast outcomes, eliminating or palliating uncertainty (which is intrinsic to any project). Using the WBS and CPM as input, the system integrator needs to track the progress of each task (labour and procurement), so that the value of the project is built up. Based on the data input, and using the formulas included in the EVM tool, the system integrator can state with certainty the current status of the project at any given time, as well as creating a forecast (which is based on the registered data so far). Please refer to the “Basic Concepts” chapter for more information, including a practical exercise.
Change Order Management
Tracking changes in the project must be an activity that any system integrator performs when carrying out a project. Using the EVM as input, the registered changes will, most probably, affect the outcome (scope, budget, finish date…), hence it has an impact in the work performed (labour and/or procurement). It is a common mistake not to track the changes, thinking that the value is small compared to the total value. This could be considered a continuum fallacy, since the system integrator tends to think that between a small expense and a large expense there is a big gap which is never filled. Truth is that only tracking the changes and its additional expenses the impact can be evaluated at the end of the project. When a change is registered, the EVM must be updated accordingly, drawing a new baseline if necessary.
Many things have been already said about the learnt lessons over the previous chapters. Summarizing:
- Learnt lessons capitalise on the knowledge acquired on each project, thus building a repository to be used for future reference.
- The action of writing down the learnt lessons at the end of each project becomes a great exercise to reflect about the acquired knowledge, what went well and what went wrong.
- Learnt lessons are an amazing source of data to produce stats about performance and ROI.