A1: ABSORPTION RATE

For the purposes of Project Management, I will keep the definition simple and not aligned with the technical accounting definition. In projects there will always be costs that cannot be recouped from clients or business units internally. An example can be the easiest way to explain it.

If the budget for a client-based project is €600k and the contract is fixed price, then any costs incurred over the €600k and out of contract cost will need to be absorbed if they cannot be recouped from the client or another business unit internally. If all costs incurred over the €600k are absorbed, as in they cannot be charged to the client or other business units internally then the absorption rate in simple terms is 100%. If half the costs can be recouped, then the absorption rate is 50%. If part of the cost can be recouped from clients or allocated against other business projects or units internally then the absorption rate will be a variable amount depending on the amounts recouped in question. Therefore, the absorption rate is the percentage overrun in budgeted costs that cannot be charged against clients or recouped internally, and not anticipated at the outset of the project. 

Note: Project accountants will calculate the exact rate, the project manager should monitor and manage the costs accordingly.

A2: ACCEPTANCE CRITERIA

In a typical project delivery whether the methodology is waterfall, agile or hybrid acceptance criteria is needed before one phase can be exited and another entered. Predominantly acceptance criteria are used during the testing phase, but it can be used for requirements and design phases too. For example, the accepted criteria for entering a design phase would and should be that the requirements are finalised, agreed and signed off by all parties notably vendor and customer. 

Within a testing phase, testing can be broken down into numerous elements such as static, unit, system, system integration, penetration, volume, user acceptance testing, end to end testing and so on. The criteria here could vary but may include that 90% of all primary or critical tests need to be passed in order for a testing phase to be closed and a new one entered. The percentage could be as high as 100% and the technical and intricate detail of such criteria will be agreed in the testing strategy document. 

The criteria could be broken down into low level details such as priority 1 tests, priority 2 tests and so on. If defects are found each defect may be then categorised as severity 1 defects, severity 2 defects, etc. The acceptance criteria for these may differ again but normally will be 100% for severity 1 defects and weighted down as the severity level decreases. For example, the criteria could be. See below.

Severity Classification	Categorisation	Tests % needed to sign off
P1	Critical – All tests are essential for the testing phase to complete	100%
P2	High – The majority of tests are essential for the testing phase to complete. Discretion can be taken for some tests deemed non critical	>85%
P3	Medium – A relatively medium % of tests are needed to be executed and passed in order for phase to complete	>70%
P4	Low – A relatively low % of tests are needed to be executed and passed in order for phase to complete	>50%

The above table illustrates an example of potential classification used for acceptance criteria for the testing phase of a project. The % of tests needed to pass in each severity classification is not set in stone and can be different for every project deployment.

For the wider project incorporating all phases the detail of how acceptance criteria are implemented in the project will be held and agreed within the project charter, project initiation document or something similar.

A3: Accessibility

Accessibility is a term that is used when delivering predominantly information and system-based projects. At a simple level accessibility means that’s a system is designed so that in can be accessible easily by end users. A simple example is when web designers design a website, accessibility would concern whether end users have access to devices where they can view the website, so laptops, desktops, iPad, iPhone etc. Developers are aware that text reads differently in desktop, tablet and mobile formats and therefore websites are developed with these formats in mind as to make the site more dynamic in nature.

To access the website end users will need access to the internet and hence access to a working broadband connection. Accessibility should not be confused with usability which ultimately is about how the end user uses the system or website. Question posed could be – Is it user friendly? Can the user navigate seamlessly through different pages etc.?

A4: Achievements

During any project, it is important as a project manager to note all the achievements that have been made by the wider project team. Projects can be arduous at times with delays and overruns sometimes having a negative effect on team morale. So, no matter how small an achievement maybe it is important to note these at a team level and steering committee meetings. Achievements can include requirements / design / build and testing stage completion. Or it might be as simple as closing out an action that has been ongoing for some time. The main achievements in any projects are linked to the agreed milestones that should be contained within the signed project charter, initiation document or similar document. Contracts sign off, project kick offs, requirements completion, quality gate & phase exits and go live could constitute the main achievements in any project but there are many to choose from. Main aim is to keep your team motivated by recognising good achievements as they happen.

A5: Actions

During the running of formal or even informal internal or customer meetings actions will arise. These actions need to be noted down, (normally by the project manager or chairperson) assigned an owner and distributed out to all attendees after the meeting. If the meeting is a recurring one which takes place weekly, bi-monthly, or monthly then I believe the best way to manage and track the progress of actions is via an action log. Therefore, each action can be tracked for progress each week and each assigned owner can update the meetings attendees and the project manager accordingly. I believe the following are key to maintaining an effective action log.

• Action identifier – i.e. No 1
• Issue description (of the action) – this should include a concise description of what the action is, who it affects and the desired output.
• Project phase – Note the phase of the project it is affecting, example below – requirements / design / build / test / deploy as part of a conventional waterfall methodology.
• Impact on go live – list whether the impact on go live date is either high / medium or low. So, if its high then the action is deemed high priority as it affects the critical path and could mean the go live date is delayed if the action is not resolved quickly. Medium means it could affect the go live date but more than likely will not. However, it needs to be monitored closely so that it does not move to high priority and its target date for closure needs to be adhered to. Low means it will not affect the go live date but still needs to be tracked until its closed out.
• Owner name – ideally one individual but can be jointly owned if deemed necessary.
• Owner Company or / and Business unit – so if you are dealing with a customer, the owner could be the vendor or customer. If the project is in-house, the owner may be a colleague in a business unit i.e., Finance or Human Resources
• Status of the action – should either be Open, Work in Progress (WIP), On Hold or Closed. The difference between Open and WIP is that an action can be new and just opened but no work has been done to progress it, so it is deemed Open. If, however, work has begun to complete the action and close it out, the action then it is deemed a work in progress (WIP). Closed is when the output is complete, and the owners of the actions log agree to close it out. On hold actions are actions which will not close in the short to medium term and have other factors affecting it that are preventing it from progressing so that it can close. In my opinion if it is known that an action will not close in the next 2 months then it is advisable to categorise it as On Hold. For presentation it looks good to conditional format (in Microsoft Excel) the cells so that each status category is colour coded. Open is red, WIP is amber, Closed is green and On Hold is blue. Validations and drop-down filter boxes will aid this too.
• Date opened – note the date the action was added to the actions log.
• Target date – note the date against which you are tracking against for full closure.
• Date closed – note the date the action was closed as agreed by the action log owners.
• Notes / Comments – it is advisable to include this column to note weekly progress.

Below is a simple example of an actions log but the content and columns can vary depending on the nature of the actions being managed. Not all columns have to be included as listed above, (list above is guide only) as a project manager use your discretion as to what you need.

A6: Activity

In project planning an activity is the same as a task and the two words overlap and get used in the same context. Tasks and activities get assigned to resources and durations and dependencies are tracked in the project plan by the project manager. These can be managed by using activity sequencing (lists) and activity network diagrams which will be discussed in the next blog.

Please leave any comments you have. Part 2 in the A series will be posted in next two weeks. 👍

Thanks for reading