Whatever project you're working on, in whichever sector of business, you are likely to start collecting a series of issues with that project which need to be addressed. Those issues could be of pressing concern right now or they may not require any attention until a much later stage of the work. When there are only a few issues we can all manage them through our normal daily workloads, but as the number of issue grows, the task of managing the issues starts to become non-trivial. This article delves into why it is important to deal with the ever growing load of issues and how we should go about dealing with them.
Being long enough in the tooth, I remember when there was no internet. I have watched with keen interest the development of communications technologies through dial-up to 4G and more latterly new wireless technologies aimed at IoT like SIGFOX and LoRa. During that time, I have worked on a number of communication projects, but most recently I have been heavily involved with telemetry in the UK Water Industry.
Utilities companies within the UK water industry would normally have many thousands of devices deployed to monitor their estate. Those devices would likely have been deployed over many years; with some devices in the field being new and others much older. It is a non-trivial process replacing and maintaining all that equipment and the industry therefore moves at a slower pace than other cutting-edge young industries. The utilities companies were however very interested when early machine-to-machine (M2M) communications became possible with mobile 2G networks. With the advent of improved battery technologies and mobile communications it became possible to deploy telemetry in locations which had neither landline communications nor power.
In this article I’ll go through the basics of “project triangle principle”. [Sometimes referred to as the "Iron Triangle" or the "Triple Constraint"]
The Project Triangle theory is interesting because:
- It applies to most, or arguably all, projects; covering a very wide range of sizes and subjects
- It gives a vital frame of reference for managing a project, and helps you, as the project manager, to understand that there is an interplay of constraints at work and that varying one key aspect of a project is likely to have knock-on effects on other aspects
Most project managers will be familiar with this concept, but many of you who haven’t “formally” managed a project will no doubt have managed “projects” in your personal lives and will recognise the concept. You are likely to be, or have been, a project manager – whether you have been given that formal title or not!
WITS is the Water Industry Telemetry Standards group. The group was set up to look after telemetry standards in the Water Industry and in particular the WITS-DNP3 Protocol.Traditionally water companies could only use proprietary devices which utilised the same communications protocol as their telemetry systems, limiting the water companies choice in devices. The WITS-DNP3 Protocol allowed water companies to utilise telemetry devices from various vendors on their telemetry system and hence control costs and select more effective equipment. The WITS group is made up of water companies (a combination of WaSCs and WOs) and telemetry equipment vendors or related companies. Terzo Digital were recently elected onto the WITS PSAC for a further two years. The article below was produced for WITS and is available here on the WITS website.
So you are considering implementing a WITS Field device? This article provides an insight into the factors you may need to consider and the steps you may have to take to do that. By pulling together some of the experiences of current WITS device manufacturers on the PSAC, it also provides a glimpse into the types of issues that others in your position have found important.
To explain a few terms before we dive in to the article, the protocol is called WITS-DNP3 as it is based on DNP3, for the remainder of this article we will just refer to it as the WITS protocol. The PSA is the Protocol Standards Association, set up to manage the protocol and any other protocols developed. The PSAC is the PSA Committee, a group of six users and six vendors of the PSA who are voted onto the PSAC by the members of the PSA every two years.
The majority of the article is presented in an informal and anecdotal style giving you an unordered list of things to consider, together with why they should be considered. The article ends by pulling together a roughly ordered list of the things you will need to do during planning and development. Remember though that each vendor organisation is likely to have a different experience depending upon their exact situation, so please treat this in the advisory sense in which it is written.