A project scope document should clearly communicate the project objectives, goals, deliverables, roles, and responsibilities early on. There is no set template to determine what a Scope document should include, not include, or look like for all projects. However, all projects do have certain things in common such as a project owner, an end-user, certain goals, an approved budget, a start date, an end date, and specific deliverables. We have narrowed it down to the following documents as rather necessary.
- Project objectives and goals – It is vital to understand the customer, their business vision and their expectations of the product or result. Our job is to plan and executed the work within the boundaries of the customers’ project objectives and goals. This requires as much input from all relevant stakeholders – project owner, end-users, suppliers, technical and operational experts for us to advise and strategize the right solution.
- User Requirements and Specifications – The URS is generally a planning document, created by the customer to describe the business needs, design specifications, risk assessment (hazop), integration requirements, wiring standards that the system, product, or solution must adhere to.
- Functional Design and Specifications – An FDS document describes at a high level how we plan to implement the product or solution; how products and layers of technology will integrate with each other, and how users will interact with the product or solution.
- User Interface Standards – This document will describe the graphical interface, colour scheme, object library, operator actions, security etc. It’s a complementary document to the FDS document and deals with the Scada standards at a lower system level, pertaining to the User Interface, wiring and interlock standards, faceplates, colours, navigation, and other visuals.
Often, scoping and planning phases are completely bypassed due to strict timelines and management pressures to get the solution in as soon as possible. The PMI Pulse of the Professional found that an estimated 37% of all reported projects fail due to unclear project objectives and communicated milestones. There are situations where unplanned shutdowns or breakdowns will dictate the situation or global shortages on IC’s will have an impact on manufacturing and the supply of electronics. Events such as this are out of our control. But where possible a project should always be planned and scoped first and authorised.
Scope documentation also establishes a boundary between the contractor and the end customer early on. It creates trust a sense of control. Yes, it should still be managed though, but with clear project goals, objectives, and deliverables many of the usual project mistakes and finger-pointing can be eliminated.
Not communicating when things go wrong – The rule for risk is to immediately inform the relevant person when things do not go as planned. The main driver for people not wanting to report problems or when things went wrong is fear. People then tend to rather try and sort out things by themselves, keeping quiet about it, or rock up late in the hope that no one will notice or find out. That does not help anyone. Company culture and management styles usually need to adapt first to fix this before moving on to more drastic measures. Build the trust, have an open-door policy, praise people in public, never discipline in public, show interest in what they do, implement communication tools, collaborate more often, listen to their ideas, learn from past mistakes and experiences, and work together as a team. There is a lot of value in getting informed about a mistake or a possible risk immediately or before it even occurs. It enables you to sort it out quicker, involving the right people and to save time, cost, and perhaps even lives.
Not following or implementing change control procedures – Change control procedures prevent engineers from gold-plating projects and customers from changing goal posts or project deliverables. In project management, scope creep is when extra features are added to a project at the request of a client but without proper authorisation. Gold plating, on the other hand, is when a project team or member adds on features that were not requested or ordered by the client hence using company time unlawfully. We encourage change and improvements to the original plan; however, this needs to be managed and approved first. Changes will almost always have a direct impact on either cost, time, risk, or quality and this must first be quantified and then approved before implementation.
Not tracking time – Time is one of the major project constraints, it, therefore, makes sense to track time spent on project activities. Time equals expense. Time also equals quality so there is this balance one need to maintain. Time also equals profit and therefore project performance. Logging time spent on project activities do create trust between you and the customer and keeps teams members accountable for their part. It also helps us to understand where projects went wrong, where we underquoted or where we overcharged to remain competitive, yet profitable at the same time.