A21: ASSUMPTIONS

Assumptions in the project management domain are contained within the RAID log which contains all the Risks, Assumptions, Issues and Dependencies for each project. They are normally tracked together, with Risks and Issues given greater weighting within a project. Assumptions should contain anything at the beginning of any given project that can be generally assumed will or will not happen and they must be able to be tracked against. For example, it may be fair to assume that the internal testing team will perform testing in all its guises except UAT. Another example may be that the project team can be adequately resourced. Events that may change these during a project are annual leave, staff leaving, redundancies, project budget etc. One cannot predict the future but some assumptions should be clear at the beginning of each project and captured within the RAID log.

A22: ATTRIBUTES

Attributes is a term that is used in coding by developers. It is a term that project managers will more than likely come across if they are attending technical coding and developer meetings. Essentially attributes are akin to metadata which is breaking down data with more data and explaining the functionality of such data. An attribute of an object can contain a name and a value. For an element it can be a type or class name or for a file its a name and extension. Each attribute can have certain rules attached, for example character length could be capped at four. The usage of attributes is different in programming languages such as C#, HTML, Java, JavaScript and so on. Attributes are not the same as entities. Attributes will describe the characteristics of an entity. So for example in a data table, the entity could be a college campus and the attributes could be students, courses, lecturers and so on.

If a project managers background is in technical software application delivery, then they will possess a good knowledge of attributes and coding but it is not necessary to perform project management duties.

A23: AUTOMATION

In simple terms a task can be automated or manual. Automation is about reducing the manual intervention needed by humans in completing a task. The first automated or semi-automated devices I would have used as a boy would have been a tv remote control and a cd player. These simple automations have increased and changed over time to include Bluetooth and voice activated controls for devices. Automation requirements, design, build, test will need some human interaction. However, the end output should be that the product or service being built and deployed is automatic. The technology used should mean human interaction is rendered redundant or at a minimum is only sparingly needed, i.e., to plug a device into a power source, etc.

In recent times the term AI which is artificial intelligence has been used in tandem with automation. The concept simply revolves around the idea of using technology to replace or reduce the need for human activity in the performance of day-to-day tasks. A prime example of this is now used in customer support where most internet or television companies use webchat or virtual supports to aid you when you have a query. The idea is to prevent the customer calling the vendor and the target output for the vendor is reduce human contact and thus reduce costs. Invariably though these automations can have teething problems and need tweaking for them to run smoothly.

Within the project management domain more project managers are getting exposed to automation-based projects. This phenomenon is likely to increase in the next ten to twenty years with many service providers looking to reduce cost by increasing automation.

AI will most likely lead automation in project management in the years to come and already some companies are embracing its capabilities. The more administrative and mundane project tasks such developing project plans, reporting and documentation should be able to avail of AI and be automated which should allow project managers to focus on higher value tasks and at a simple level manage more.

A24: AVAILABILITY

Availability is a term used in tandem with resourcing. Simply “availability” is used to describe whether a resource (normally a stakeholder in a project) has the capacity to complete a task as per the assigned timeline in a project plan. If the resource can complete the task as per the plan, then the resource is deemed available. If the resource cannot complete the task, then the resource is deemed unavailable and a workaround or replan may be needed. Availability of resources is essential for a project to meet expected milestones. It is normally up to the project manager to manage resourcing and availability of such resources during the project. 

A25: AUDIT

When we traditionally think of audit we can view it as a one-dimensional element of accounting normally broken down into internal audits run solely inhouse or external auditors which tend to be regulatory based audits as dictated by international accounting standards. However, my experience of audits within projects tends to be audits that are focused on information technology platforms and the security and access of such. Information security officers or a member of the security team will tend to be in control of all information technology audits. Internal and external audit questionnaires and reviews will be fed through this business unit. Customers will send audit questionnaires to vendors requesting information and answers on security, controls, accessibility, data protection and compliance questions. The list mentioned is not exhaustive and due to data sensitivity and the advent of GDPR in 2018 the information companies can request and ultimately release is governed by legislation.

A26: AUTHORITY

If you are in a position of authority, you have the power to not just plan but to make important decisions. In projects it is normally the project sponsor and not the project manager who has authority. The project manager is responsible and invariably accountable for projects being delivered on time, within budget and scope. Having authority or power to force stakeholders in the project team to execute certain tasks is not part of a project managers remit. This can make the job of a project manager challenging and at times frustrating.

Below is an extract from the PMBOK, a table titled influence of organisational structures on project managers. 

I believe it gives a good overview of authority levels project managers face in organisations. The first column gives an overview of project managers authority divided out between the different organisation structures. Not all organisations will conform to the table above as all organisations are unique in how they structure and govern projects and this has a knock-on effect on the levels of authority a project manager will have. 

In my experience most companies’ structures lie somewhere between the balanced matrix and strong matrix. The reality is there are very few structures that give project managers autonomy to make decisions and most project managers will have authority that is low to moderate or even no authority at all. Some structures will give the project managers a moderate to high level of authority but in my experience, these are the exception rather than the rule.

If you look at the next box in the left-hand column ‘Project Characteristics’ this is resource availability. Resource availability differs in all organisations but normally is moderate or adequate in nature. My experience is most organisations have developers or / and development teams. However, depending on structures these teams can be centralised which can mean having locally available developers may not be possible or thin on the ground. Some organisations have business analysts, change managers, test manager but a lot don’t and if this is the case the project manager will invariably end up double and triple jobbing to cover these roles. Next is who manages the budget – this can depend on the nature of the business. Professional services organisations who charge customers for their services and products will try to manage costs carefully and project managers will be asked in some part to manage the budget. In other organisations it can be the sole responsibility of the Project Management Office (PMO), sponsor or accounts departments. Projects manager will always be hired on a permanent basis whether contract or salaried unless the project is so small it dictates only having part time project manager. This is quite rare. For larger organisations with a vendor / customer model PMOs are common and for organisations where projects tend to be more internal based PMOs are less common and if they do exist will be small in nature. 

To summarise the table gives a good overview of the authority levels that can exist in organisations. The list is more a guide and should be taken that way but as mentioned my experience tells me most organisations fall between balanced and strong matrix structures.