The new Knowledge-base.
Hey, you just created a text paragraph! Somebody once said that the pen is mightier than the sword — and that was in 1839. Just imagine, with the power of digital publications and the ability to distribute your content around the world in mere seconds, writing this paragraph could be one of the most influential things you ever do!
You may have seen on Hive recently that we have launched a new and improved Knowledge-base. It’s now integrated with SharePoint, meaning it’s now fully incorporated within Hive, easier to use, search and navigate.
Here’s a video that takes you through all of the main features, and you can find more detail in the Hive news item.
It’s worth familiarising yourself with what’s available in the Knowledge-base, as it will save you time and trouble in the long run. The Knowledge-base is filled with content and information that can help make your projects more successful. You won’t have to keep reinventing the wheel, and you can have confidence that the firm’s standard documents and tools have been thoroughly researched and peer reviewed by experts in the subject. We’re particularly proud of the new Knowledge-base, as we feel it embodies the Technical Control group’s vision:
“Every engineer utilises the knowledge of the whole firm to make the firm’s product better and/or produced faster.”
Although we work behind the scenes, the TC group is here to support you in: - Doing the best job that you can technically, as efficiently as possible; - Keeping up-to-date and developing your technical knowledge and skills; - Resolving technical issues to get to a solution more quickly; - Managing technical risk for both the firm and your clients; - Sharing your knowledge and expertise with the wider firm. We’re also continually looking to improve, so if you have a suggestion or an idea for something new, please let us know. You can even go one better: if you have some knowledge, expertise or a document/tool that others could benefit from, please get in touch with us to talk about how we can collaborate to get it on to the Knowledge-base.
Technical Control myth-busting
Bulletins: they have a nasty habit of building up and signing them off becomes yet another task that we don’t have time for. But I want to convince you that it doesn’t have to be this way!
Myth: “There are so many bulletins to read and sign off, it’s a burden.” Fact: On average there is less than one bulletin issued per month and they are usually less than two pages long. While you are notified separately of changes to other standard documents, it is only changes to key policies and guidance that require bulletin sign-off. Myth: “I don't need to read the bulletins as soon as they're published.” Fact: It’s less time consuming (and less embarrassing) to avoid known problems and risks in design than sorting them out later, particularly once the project gets to site. Myth: “I’m being sent bulletins that aren’t directly relevant to me.” Fact: If you're an MEP Associate or above you'll be leading projects, so you need to have a broad understanding of the important issues in your opposite discipline as well. We identify, for each bulletin, which specialist groups need to sign it off, in consultation with the specialist groups’ TC representative. I also wanted to offer a hint around a classic dilemma with our ‘standard documents’. Dilemma: “Using the standard documents doesn’t always save time - it takes longer and may produce a document with more detail (and bigger) than my client wants.” Here’s my advice: Consider what information we need to communicate to discharge our duties, not just what sort of document the client wants, or thinks they want. Bear in mind that the standard documents have been thoroughly researched, and peer reviewed by the firm’s subject matter experts, and are periodically updated. So, you’re better off using them as your starting point than a previous project or a blank piece of paper. Action: Use our standard documents to begin with; if there is still information in the standard reports or specifications that isn't relevant, or doesn't need to be stated for your project, it's absolutely fine to leave it out.