Skip to main content

Project Management

Policy for Project Management

A policy for reviewing and managing the performance of projects should be approved by the Board and implemented by the executive of the CRC.

The policy may require each project to be described in a project plan, along with milestones, deliverables, payments, and risk mitigation measures. It should identify and describe the role of a Project Manager for each project. It should also describe any dependencies and links to other CRC projects.

In addition, each project plan should describe how they will lead to commercial, social and environmental impact, either directly or indirectly, and describe the process and organisations that will be required to achieve those outcomes.

The policy should outline the agreed process, timelines and responsibilities of project review, and how poor-performing projects will be managed. Ideally, this would include a project review template for project managers should submit to the delegated officers of the CRC.

Business Administration Systems

This section outlines the business administration systems that need to be rapidly established to ensure the efficiency and safety of a new organisation starting up. It can be costly and time consuming to change an underlying software platform, so making the right decision early will save time and money later.

Cloud Platform: Google or Microsoft

A key decision to make is whether to use Google or Microsoft.

The Google system is much cheaper, is less clunky and is arguably easier for document sharing. All of Google’s systems are browser driven and based on the cloud, and you get access to most of the system of apps when you sign up for a Workspace Account – upgrading the account generally gives more security and access to more data storage and video conferencing. It can be more difficult to engage people into the collaboration spaces who don’t have a Google account.

Microsoft is better integrated with Office tools such as Microsoft Word, Powerpoint and Excel and is often used by government agencies who find it difficult or impossible to formally work with Google workspaces. Microsoft systems are not intuitive and their website is not particularly informative, so you may need to hire a specialist consultant to assist you to extract the full value from a very deep and complex technology stack that may require additional licenses (and cost) as you use more of it. It can be quite difficult to engage people into the collaboration spaces who don’t have a Microsoft account. If you work in security sensitive areas like defence, you will need to download patches and change setting to strengthen the security of the Microsoft stack.

Not for profits, including CRCs, can usually negotiate a big discount on some Microsoft license costs.

Really understand the relative benefits of each so you don’t set up under one and then find that you have to switch mid-stream – it can be very expensive.

In the end, you will probably go with Microsoft because government partners can engage more easily.

Document Management

Setting up a robust filing structure early on is essential to ensure files and folders are well organised and can be easily and intuitively accessed by the whole team (not just the creator). Failure to do so can result in significant lost time and expense in trying to track down the right file and version of the file.

In addition, file and folder naming conventions are key to maintaining well-organised electronic directory and drive structures. When used consistently this means:

  • Files are easily distinguished one from another
  • File names are easier to browse
  • Retrieval is facilitated for all users (not just the file’s creator)
  • Ensures document version control

It is good practice to develop a Naming Convention Protocol for the team to become familiar with. See example of Naming Protocol here.

Filing naming best practice

·        Keep file names short but descriptive (<25 characters)

·        Avoid special characters

·        Use underscore or dashes instead of spaces or slashes

·        Use date YYYYMMDD at the beginning of the document name (ie 20230201_Smith_Letter) – this will facilitate computer aided date sorting)

·        For revisions of documentation such as reports, legal agreements etc use a version number (ie V01, V02) at the end of the file name

Elements to consider when naming documentation

 

·        Date of creation (putting the date in the front will facilitate computer aided date sorting)

·        Short Description

·        Work

·        Location

·        Project name or number

·        Sample

·        Analysis

·        Version number

Back to top