How accounting can empower better project management

Accountants are a natural ally for anyone hoping to get things done within an organisation. They know the transaction flows of the organisation and the risks and controls around its processes, and that knowledge can provide a valuable road map for those tasked with product design, process improvement, and more.

To maximise their utility, accountants need to speak one of the most important languages of modern business. They need to understand project management, the methodology by which many business leaders enact business improvements and technology innovation.

Accountants who learn the flow and terminology of project work are better able to serve as business partners for teams outside of finance, and they'll be better positioned to advocate for good financial, data, and process management practices.

In short, those in finance who understand project management will be seen more like enablers and less like gatekeepers.

Following the project flow

A project is defined as a temporary endeavour that creates a unique product, service, or result. That could be a brand-new consumer product, an enhancement, or simply a process improvement.

A project represents change, and change brings risk. Our job, as accountants, is not to minimise that risk but to help manage it — and project management methodologies aim to do that by mapping out the elements of the project, identifying their relationships, and evaluating the potential risks that come with them.

The document that encapsulates all that crucial information is the project charter, created at the start of each project — and it's the key to understanding the process to come. The charter is essentially a contract between the project team and the rest of the business. Just as you use contracts to manage outside vendors' performance, you can use this document to set realistic and enforceable expectations within the organisation.

In most cases the accounting function isn't in charge of these projects, so the management accountant won't be the one actually drafting the charter. Instead, your role is to objectively review the information and assumptions that are going into this document.

Rather than coming down as the gatekeeper at the end of this process, you can be more effective by working earlier with a project manager to ensure that good projects get through the gates. The timing of your involvement will vary from project to project, but it's ideal to join during or before the drafting of the project charter.

Managing project risk

No project charter, no matter how good it is, can predict all of the causes and effects at play around a project. Even if it did, someone would still have to manage those risks.

These project risks become more obvious — and more real — as the actual work of the project starts. For example, an architect might forget to make a public building accessible to people with disabilities, or an IT person might omit approval threshold controls from a procurement application.

Anything can happen, and that means that the accountant's job only becomes more important as the actual project gets underway.

A few key strategies will help guide you along the way:

• Stay involved with the project. Attend meetings. Ask to be included with correspondence, and follow along with the team. Monitoring the work as it happens will give you a better understanding of each component's context and help you identify emerging risks. Your degree of involvement will change with the project — more risk, more involvement — but there's often a sweet spot between "uninterested" and "over-controlling." Your goal is to be accessible and present while respecting your role as a supporter and guide.
• Think like an auditor and ask the right questions. Stakeholders and subject-matter experts can help you identify the relevant business rules and controls that apply to each segment of the project, which you can then use to "audit" components as they're completed. For example, an operational person may know that there is a potential problem when a particular ratio goes above 10%, and definitely a problem when the ratio goes above 20%. A detective control could be designed into the project to appropriately flag transactions that reach those ratios.
• Beware of workload spikes around major deliverables. If you only get involved as the deliverable approaches, you're going to get hit with a pile of work once the deliverable is ready, and you may then be seen as a bottleneck to completion. Continued involvement with the project will minimise the amount of backtracking, retrofitting, and panicking you have to do — all of which, by the way, becomes costlier as the project progresses.

Dealing with scope creep

Almost every project will run into "scope creep", the phenomenon that drives projects outside of their original scope or violates the assumptions and constraints described in the charter.

As a project evolves, you're going to encounter unexpected scenarios, find gaps in the original plan, and hear demands for more features without a corresponding increase in resources.

Maybe your credit card processing company now requires a new level of security. Maybe a whimsical idea has made its way down from the C-suite. The management accountant's job through all this is to uphold the project charter — the original contract between the project team and the rest of the business. But that doesn't mean that the project charter is unchangeable. When a change is properly justified, it can add value to a project.

So your role is to act as the validator, treating each proposal similarly to change orders submitted by vendors.

Think of project components in terms of "must have", "should have", and "nice to have". If a project component is in one of the latter two categories, then the project team needs to provide an assessment of the value the change would provide versus the additional effort or cost.

If the benefits don't justify the cost, then perhaps the scope change should be denied. Otherwise, the threat of "scope creep" may draw the project away from its original purpose and beyond its budget. Alternatively, a request for a major change in direction might signal that the project itself is misaligned with the company's current direction and may no longer be necessary.

Sometimes this oversight role can put a management accountant in an awkward situation. Requests for a change in scope or direction might have a lot of momentum behind them when they cross your desk. But if you're involved early and you keep your perspective objective and fact-based, then you'll help ensure the project is oriented with the best results for the organisation in mind.

Closing the project

People tend to forget the closing phase of a project's lifecycle, but it's crucial to improving the organisation as a whole.

Often, the focus at the end is on getting sign-offs from sponsors and handing over operating procedures to operations. However, the most important aspect of closing is capturing the lessons learned. This is when you can pinpoint problems in your project processes, evaluate the project as a whole, and ensure that the knowledge you've gained from the project isn't lost.

Management accountants in particular can use this time to assess whether and how risk management has been enacted at the project level. Did you help the project move faster and more smoothly through the organisation? Or were you a gatekeeper who held things up?

Donny Shimamoto, CPA/CITP, CGMA, is the founder and managing director of IntrapriseTechKnowlogies, a Hawaii-based CPA firm focused on organisational development and advisory services.

Charter chatter

Charters vary by project, but the general template includes these details:

• A list of your own key project team members and their roles, as well as the senior-level sponsors who have approved and will support the project.
• Your stakeholders. These are the people who will be directly affected and who have the power to affect your project. They often will have a role in accepting the deliverable. This might include your management, accounting, and IT teams. These people can influence your project for better or for worse. By identifying them early, you can keep them on board with the project.
• The objectives or outcomes that will determine whether the project is successful. Outcomes are about a desired state, or a condition, such as the reduction of risk or a better understanding of the cost structure. You may also include value statements, describing how accomplishing that objective will benefit the organisation.
• The specific goals that will serve as the project's milestones. For example, to reduce risk, you might need to create a new way to assess contracts. These goals in turn can be mapped to the deliverables that you'll create at various stages. For example, you might need a proof of concept early in the process. These deliverable dates can be detailed in a summary schedule.
• The assumptions governing the project. An assumption is an external factor, outside of your control, that you're dependent upon. This can include your financials, but you also need to document the other resources that you'll need. For example, your project may need an employee from IT. You don't control IT, so you need to document that assumption. You'll also want to list any required approvals and create a summary budget.
• Constraints. These are limits on your work, such as a lack of available employee hours, a hard deadline, or a spending limit. Putting these factors in your charter can help to communicate the limitations that the project is operating under.
• Interdependencies. These show how a project interacts with other work going on in the organisation. Maybe your work can't proceed until a piece of software is updated. On the tail end, other projects might be waiting on yours to be completed. If they're not surfaced, these relationships can allow for disastrous ripple effects.
• The risks the project faces and the relevant mitigation plans. This is obviously the management accountant's specialty, and documenting these risks can steer your project clear of undesirable surprises.