If you are a ‘problem solver’ like me then you may have come across a game called Geoguessr. The principle is very simple, which its that you get given a random google maps location- anywhere in the world – and you need to identify where it is. The clock is ticking and the close you are, the more points you get. A great guess is within a few hundred kilometres….a perfect guess is within a few tens of metres.

If you are lucky, you might get a street sign or something that gives you a big clue. This is an example of what you get:

Based on a quick look around I was thinking southern Europe only to guess Spain when it was in fact Greece:

You’ll notice that 5000 is the maximum number of points, so I only achieved 26% of the maximum points available. This is not considered a good result.

There is even a world championship for Geo guessing and people who do this full time often share videos of their techniques to solve the puzzle. In these videos they explain that they look at different types of pylons, road markings, shadows from different types of Google cars, foliage, location of the sun. They build up an encyclopaedic knowledge of the differences country-by-country.  It’s impressive to watch them at work.

So, to this end, I want to use this blog to explain something similar to you which is how I go about using Oracle AI Success Navigator or “CSN” as we are still calling it to use it as a detective tool rather than just sharing the actual results.

I working with a client and we need a comprehensive list of business requirements to help determine which product in the market place best meets the needs of the organisation.

To this end, I’m looking to build on a previous article I previously authored. In that article I used CSN to determine a complete set of business requirements for employee expenses. In that article I used CSN to discover 20 business requirements for employee expenses. What I want to do now, is use the same approach to discover business requirements for every other area of a finance system (of which employee expenses is just one part). 

Defining the problem

I’ve learned over the years and through my interaction with 6-Sigma techniques, that ‘defining the problem’ requires careful thought and, most importantly, “rigour”. With Geoguessr the problem statement is easy, ‘Where am I?’. However, it is a little bit more subtle than that because there is a time limit and accuracy of location needs be balanced with how long is being spent on looking around. So a Geoguessr’s first question is “which country am I in?” Followed by “which part of the country am I in?”. 

To this end the problem I am trying to solve is not only to create a list of requirements for a finance system but to be confident that I haven’t any areas that are not covered. So, it’s ok to ask CSN:

create a comprehensive list of business requirements for a new ERP finance system

And with some trepidation this is where I start.

The results, on the surface certainly look promising. CSN starts off with letting me know the overall business objectives and outcomes:

Provide a single source of truth for financial data

Standardize finance processes across business units, entities, and geographies

Improve financial visibility and reporting accuracy

Reduce manual effort, spreadsheets, and duplicate data entry

Strengthen internal controls, auditability, and compliance

Accelerate period-end close and financial consolidation

Support business growth, acquisitions, and organizational change

Enable better forecasting, planning, and decision-making

Improve cash flow management and working capital visibility

Support automation and scalable finance operations

CSN then provides a series of categorises and a list of requirements against each. For the functional areas this looks like:

Row Labels	Count of requirement
2.1 General Ledger	11
2.2 Accounts Payable	12
2.3 Accounts Receivable	10
2.4 Cash and Treasury	9
2.5 Fixed Assets	8
2.6 Expense Management	7
2.7 Tax Management	6
Grand Total	63

In addition, there are a further 136 requirements by the following areas:

Row Labels	Count of requirement
10. Compliance, Risk, and Audit Requirements	9
11. Workflow and Approval Requirements	6
12. Master Data Management Requirements	6
13. Integration Requirements	9
14. Data Migration Requirements	8
15. Security Requirements	7
16. Usability and User Experience Requirements	7
17. Performance and Scalability Requirements	5
18. Configuration and Administration Requirements	5
19. Controls and Exception Management Requirements	6
20. Document Management Requirements	5
21. Implementation and Transition Requirements	8
22. Non-Functional Requirements	6
3. Financial Close and Consolidation Requirements	9
4. Budgeting, Planning, and Forecasting Requirements	8
5. Procurement-to-Pay Integration Requirements	6
6. Order-to-Cash Integration Requirements	5
7. Project and Grant Accounting Requirements	6
8. Multi-Entity, Multi-Currency, and Global Requirements	7
9. Reporting and Analytics Requirements	8
Grand Total	136

This is a total of 199 requirements. 

But how do I know if it’s comprehensive or not?

Well, there is already enough information above in this article that says that it isn’t comprehensive. As mentioned above, I discovered 20 requirements for expenses alone when I specifically asked for ‘employee expenses’ and the table above for section 2.6 is only seven. So we are somewhat short. A question at this point is, “how short are we?.

What we can say is that we’ve uncovered in this latest search “nine twentieth’s of the expenses requirements” which is exactly 45%. So this implies that the above list of 199 requirements should equate to somewhere closer to 440 if it were to be ‘comprehensive’. This gives us a ball park that we need to be in…or, for Geo guessing, an indication of being “in the right country”.

So where next? 

I know that if I follow the instructions of my previous article I can discover 20 requirements for employee expenses….and I could use the above 27 headings to interrogate CSN for 27 longer lists. For example, I could ask a specific question about tax management; then about Fixed assets and then collate all the results. That would require 27 separate questions and a collation exercise. Let’s estimate that at half-a-days work.

We can test this hypothesis against one of the areas, say, tax management. The original results of CSN returned six tax management requirements (section 2.7 above) which were:

Support indirect tax calculation

Support tax rules by jurisdiction

Handle recoverable and non-recoverable tax

Support tax reporting and audit requirements

Manage withholding tax where applicable

Support cross-border and multi-country tax scenarios

o I now use a specific question within CSN as per my article for employee expenses requirements:

provide me a comprehensive table of MoSCoW use cases for the Tax Management module in ERP

So I tried that query …and it returned exactly 100 use cases. This is a 16.7 fold increase in the number we had in the original table! If this multiplier were to be applied to the 199 requirements we are now in the “ball park country” of 3300 requirements for a new finance system. This is a somewhat different answer from our estimate of 440 above!

So let’s recap on the positive progress we’ve made…what have we discovered…what are the new ‘data points’ that we now have that we didn’t have before:

1. When I ask CSN for a comprehensive list of requirements it volunteers ‘employee expenses’
2. CSN thinks that there are 27 categories of requirements/use cases to cover a whole finance system
3. For employee expenses, we get a summary number of 7 against a comprehensive answer of 20…but for taxation, the summary number of six becomes 100

At this stage, I’m only interested in collecting data…note that I’m not trying to provide an analysis or draw any conclusions from the data I’ve collected. What is important is that I stay “on mission” and keep focused on answering the question in the problem statement

It’s also worth capturing what new questions we have at this stage that we will need to resolve. At the moment, my key question is:

1.  How do I know that the 27 categories that CSN has identified is the correct number and list of categories. 

However, I also have another ‘nagging doubt question’ which is:

1. Why did CSN return exactly 100 use cases for taxation?

For me, “exactly 100” is a “spooky result that could have been a criteria of the search engine within CSN which was to have a maximum limit of 100. At the moment, this is a secondary question, the key question I need to resolve next is:

What is the comprehensive list of categories for use cases for a finance ERP system? Is it 27 or is it something else…..

I’ve been working this week with a client on building a business case and have needed to focus on explaining what the investment of an enterprise class system actually brings. There is no doubt that enterprise systems are more complex to implement but what does that extra cost give you? In this article I explore both the difference in functional and technical features.

Functional differences

1. Scope and Integration

Enterprise-class ERP System:

The key difference is that an ERP system such as Oracle Integrates multiple business functions (finance, HR, supply chain, procurement, projects, etc.) across the entire organization. Oracle has a unified data model and seamless process flows between departments. The benefits are that master data is available across modules available to different functions. For example, any structural changes in the organisation are reflected across the whole system

Department Finance System:

A standalone finance system supports financial operations within a single department or business unit.
The limited integration with other business functions or departments results in either manual handoffs between functions (such as extracting data to Excel and then emailing it to another function) or having to build technical and often complex integrations between say the finance system and sales or sales and procurement.

2. Scalability and Complexity

Enterprise-class ERP System:

Enterprise systems are designed to support large, complex organizations with multiple entities, currencies, and regulatory requirements. The need for an enterprise system is often triggered when multi-company and/or multi-currency requirements arise. This becomes especially true when the organisation is multi-national in its operations where goods are manufactured and/or stored across different legal entities in different countries. This could also be true of a services organisation delivering to customers overseas- such as a University with an overseas campus.

Enterprise systems are also designed to handle high transaction volumes and complex business processes. This can often be the case if the organisation is providing different types of products or services that have different go-to-market strategies or procurement policies.

Department Finance System:

Department systems on the other hand are suited for smaller teams or single departments that handle basic financial transactions and reporting with limited scalability. This is often single currency, single company without the need for financial consolidation and single geography. It is often where the organisation needs more than two of these features where a step change to an enterprise class system is required. Organisations where only one of the criteria is needed can often be catered to some extent by a departmental solution.

Customisation and Flexibility

Enterprise-class ERP System:

Enterprise systems such as Oracle ERP are highly configurable to support diverse business models, compliance needs, and global operations. They offers advanced workflow, automation, and analytics capabilities. The word ‘customisation’ and ‘configuration’ can often be confused. Enterprise organisations may need 5%-10% of the system to be customised but Enterprise systems often have the ability to have extension fields (or ‘flex fields’) made available through configuration without the need to ‘break-out’ of the system with custom coded scripts

Department Finance System:

Department systems often will provide some form of customisation options- such as tagging or a limited number of custom fields but it is not on the level of an Enterprise system which often allow whole forms to be customised and workflows to be fully customisable behind the scenes. Department systems focus often only core financial tasks like budgeting, expense tracking, and simple reporting.

Security and Compliance

Enterprise-class ERP System:

This is an area Enterprise systems often create clear blue water when compared to a department system. Enterprise class systems provide a robust security, audit trails, and compliance features to meet industry and regulatory standards. The level of flexibility for security and compliance then also need a Centralised set of controls for user access and data governance that enterprise systems provide. Indeed, it is not uncommon for a system, such as Oracle, to provide a set of Risk Management features to identify conflicts in areas such as, say, conflicts in segregation of duties.

Department Finance System:

Department systems do usually offer some form of basic security and compliance but they often lack advanced controls or audit capabilities. It would be possible for example to allow employees to see sales invoices but note create them.

Reporting and Analytics

Enterprise-class ERP System:

Enterprise systems have sizable and rigorous data models that facilitate advanced, organization-wide analytics and real-time reporting. Such features support strategic decision-making with predictive insights and dashboards.

Department Finance System:

Departmental systems may offer simple dashboards (e.g. for Payables and Receivables but the basic reporting focuses on simply departmental needs. These limited analytics and visualization capabilities do not support an organisation in strategic operational reporting. Financial accounting requirements are often met for reports such as Income and Expenditure, Cashflow and balance sheets. However, management accounting requirements are often lacking.

Technical Differences

1. Integrations

Enterprise-class ERP System:

Enterprise-class systems provide robust APIs (REST, SOAP), prebuilt connectors, and middleware support for seamless integration with other enterprise systems (CRM, HCM, SCM, third-party apps).
These large systems support real-time data synchronization, event-driven architectures, and secure data exchange. Enterprise systems enables integration with external partners, banks, tax authorities, and regulatory bodies.

Department Finance System:

Department systems provide limited integration capabilities, often restricted to basic file imports/exports (CSV, Excel). They may offer simple connectors for a few popular apps, but lacks enterprise-grade middleware or API management. Such systems have Integrations that are typically manual or batch-based, not real-time.

2. Mobile Ways of Working

Enterprise-class ERP System:

Enterprise systems offer native mobile apps and responsive web interfaces for key business processes (approvals, expenses, reporting). These systems support secure mobile access, device management, offline capabilities, mobile notifications, workflow approvals, and analytics dashboards. Look out for these features in procurement if mobile working is important to you.

Department Finance System:

A department system may have limited or no mobile support; often relies on desktop interfaces. If mobile access does exist, it’s usually basic (view-only or simple data entry). These systems lac advanced mobile security, device management, or offline features.

3. Artificial Intelligence (AI)

Enterprise-class ERP System:

Enterprise systems has embedded AI and machine learning for predictive analytics, anomaly detection, intelligent automation (e.g., invoice matching, fraud detection). ‘Enterprise’ often means that it offers digital assistants (chatbots) for natural language queries and self-service. Also look at for a system that provide continuously updates AI models with organization-wide data for improved accuracy.

Department Finance System:

Department systems rarely includes AI or machine learning features- however, this is rapidly clanging. Department systems may offer basic rule-based automation (e.g., simple alerts or reminders) and lack predictive analytics, digital assistants, or advanced automation.

If employee productivity is important to you then pay particular attention to the list above for the differences in AI capability.

In March I published a blog article to introduce Oracle Cloud Success Navigator (“CSN”). CSN is a new component in the Oracle toolbox and targets helping client who are in production in the cloud. However, I’ve been exploring how CSN can people projects move to the cloud.

In the previous article I demonstrated how CSN provided most comprehensive set of requirements I’ve seen associated with an ERP project- 120% more than I had seen on an average real life ERP project. The example was for managing expenses in an organistion.

What are the business benefits that CSN can identify?

Let’s get back to CSN where we left off. As with most AI tools we can expect subsequent follow up ideas to be prompted and CSN was no exception:

“do you want to explore how these use cases map to specific features or business benefits? “

This is invaluable when compiling a business case. To this end CSN tabulated the use cases and identified the benefits as follows:

USE CASE	BUSINESS BENEFIT
Employee Expense Submission	Streamlines expense capture, reduces manual paperwork, and improves employee satisfaction.
Manager Approval Workflow	Ensures accountability, speeds up approvals, and enforces policy compliance.
Policy Compliance Checks	Reduces risk of policy violations and fraud, ensuring regulatory and internal compliance.
Receipt Capture and Attachment	Simplifies audit trails, reduces lost receipts, and supports faster reimbursement.
Mileage and Per Diem Calculations	Automates calculations, reduces errors, and ensures fair, consistent reimbursements.
Integration with Corporate Cards	Minimizes manual entry, improves accuracy, and accelerates reconciliation.
Audit and Fraud Detection	Proactively identifies suspicious activity, reducing financial risk and audit costs.
Reimbursement Processing	Accelerates payments to employees, improving morale and reducing administrative overhead.
Multi-currency and Tax Handling	Supports global operations, ensures accurate tax treatment, and simplifies cross-border expenses.
Analytics and Reporting	Provides actionable insights, enables spend control, and supports strategic decision-making.

This re-enforces the benefits we identify in the business case that such a new system brings such as reducing errors, reducing financial risk and providing actionable insights. What is invaluable, is that CSN provides the traceability between benefits and the features of the system. I for one will be using CSN on my next project where we will build a business case

Process Maps as well…

One of the other areas of deep work on a project that migrates ERP to the cloud is business process mapping. I always make a strong argument that the underlying processes dont fundamentally change when moving to the cloud. Yes, its likely that different people will perform certain activity or that some activities can be automated and performed by the system. However, it is rare that we would change the commercial structure of the organisation or the financial regulations unless the ERP project was part of a larger M&A change. As an example, this is a process map that CSN provides for expense management:

This process map is ideal for a level 3 process map and the process control documentation that is often delivered as part of the project. Again, a clear example of CSN speeding up delivery.

And now test cases…

The above process flow is perfect to provide a map for testing. To this end CSN goes even deeper and provides a list of test conditions for expenses:

S.NO.	TEST CASE ID	SEQUENCE ID	TEST CASE	TEST CASE DESCRIPTION	MODULE
1	TC_EXP_001	01	Submit Valid Expense Report	Employee submits a valid expense report with all required fields and receipts	ERP Expenses
2	TC_EXP_002	02	Submit Expense Report with Missing Required Fields	Employee attempts to submit an expense report missing required fields	ERP Expenses
3	TC_EXP_003	03	Submit Expense Report Exceeding Policy Limit	Employee submits an expense report exceeding company policy limits	ERP Expenses
4	TC_EXP_004	04	Submit Expense Report with Invalid Receipt Format	Employee attaches an invalid receipt format	ERP Expenses
5	TC_EXP_005	05	Submit Expense Report with Multiple Currencies	Employee submits expenses in multiple currencies	ERP Expenses
6	TC_EXP_006	06	Submit Expense Report with Maximum Number of Lines	Employee submits an expense report with the maximum allowed lines	ERP Expenses
7	TC_EXP_007	07	Submit Duplicate Expense Report	Employee submits a duplicate expense report	ERP Expenses

further still, CSN actually provides the functional test scripts for us:

Test Case ID: TC_EXP_001

Test Case Title: Submit Valid Expense Report

Fusion Process Step: Employee Expense Submission

Role: Employee

Test Steps:

1. Log in as Employee
2. Navigate to Expenses > Create Expense Report
3. Enter all required fields (date, amount, expense type, description)
4. Attach valid receipt (PDF/JPG)
5. Submit the expense report

Expected Results:

Expense report is submitted successfully and appears in the employee’s submitted reports list.

Summary

As with all Artificial Intelligence tools, CSN is only as good as the training it has received. However, CSN is trained on the user manuals of the Oracle cloud system and provides a comprehensive insight into how each area of the system is documented and tested.

One of the benefits of being an Oracle ACE is that you get to work on problems that dont just impact a single client but can have a positive impact on a whole community. This week I was speaking to two Oracle executives in my network about unrelated challenges. The first one is why it takes clients so long to develop business requirements when we know what the product is already capable of. The second executive was looking for quantitative benefits of Oracle Cloud Success Navigator (“CSN”). So, to this end, I set myself the challenge of solving both of these problems at the same time.

What is CSN?

What if you could access the experience of over 10,000 Oracle cloud implementations to help you move your ERP system to the cloud? What if you had access to implementation guidance, milestone tracking and tools to help you with your Oracle project? Step forward CSN which you can read more about here. This article is not an in depth review of CSN but does explain how to utilise the AI assist to solve a real world project problem and to quantitatively assess the benefits that CSN brings.

Define the problem

One of the most length activities of building a business case is to derive the business requirements. An ERP implementation could have many hundreds of such requirements often specified using the MoSCoW technique. It is a myth that we don’t need requirements when moving systems to the cloud and I’ve written about this previously. I’m also going to assume that you are familiar with the terminology of MoSCoW r which requires that each statement is either a MUST, SHOULD, COULD or WONT.

In order to run a quantitative benchmark then we need define a clearly stated test. In my experience, the Accounts Payable (“AP”) process is standard across almost every implementation I’ve seen. Within AP there lies something that is even more standard which is the Expenses module. Of course, organisations will have differing expense policies but I find that the underlying requirements vary very little from organisation to organisation.

A benchmark level of effort to derive a set of MoSCoW requirements for expenses would typically be four client side people from various parts of the organisation facilitated by a business analyst in a workshop from, say, 10am to 4pm. Lets say 5 hours of 5 people (25 hours) plus 2 hours preparation. This gives us a baseline of 27 hours in total. Let’s see what CSN can do…

CSN produces a requirement specification

The Right Hand Side of CSN looks like this:

We then click on the Red and White icon which is the AI assist and get started:

I then dive in with the following query:

Not a great start. However, AI assistants are only as good as the query you use so I come at the problem from a slightly different angle:

This time CSN hits the target and I get the following:

1. Employee Expense Submission: Employees can create and submit expense reports for business-related costs such as travel, meals, and lodging.
2. Manager Approval Workflow: Managers review, approve, or reject submitted expense reports, ensuring compliance with company policies.
3. Policy Compliance and Audit: The system automatically checks expenses against company policies and flags non-compliant or duplicate expenses for audit.
4. Receipt Capture and Attachment: Employees can attach digital receipts and supporting documents to their expense reports for verification.
5. Corporate Card Integration: Corporate credit card transactions are automatically imported and matched to expense reports for streamlined reconciliation.
6. Mileage and Per Diem Calculation: The module calculates mileage reimbursements and per diem allowances based on company rules and travel details.
7. Multi-Currency and Tax Handling: Supports expenses in multiple currencies and calculates applicable taxes for global operations.
8. Reimbursement Processing: Approved expenses are processed for payment through integration with Accounts Payable.
9. Analytics and Reporting: Provides dashboards and reports for spend analysis, policy violations, and reimbursement trends.
10. Mobile Expense Management: Employees can submit, approve, and track expenses using mobile devices for greater flexibility.

The wording certainly hits the mark of the output I could expect from the workshop I’ve described above. However, I then think how many requirements should I expect to see for expenses. To this end, I looked back at a requirements catalogue from a previous implementation which had nine for expenses. So this is OK. However, I then notice that the AI assistant has prefaced the above list with the following words:

“Here are some key use cases for the Oracle ERP Expenses module:”

The use of the word “some” implies “not all”….so I ask the AI assistant a more targeted question to provide “a comprehensive list of requirements”. I get the following:

1. Employee Expense Submission: Employees submit expense reports for travel, meals, lodging, and other business-related costs.
2. Mobile Expense Capture: Employees capture and submit expenses using mobile devices, including photo capture of receipts.
3. Receipt Management: Attach, scan, and manage digital receipts for expense verification and audit.
4. Corporate Card Integration: Import and match corporate credit card transactions to expense reports.
5. Automated Policy Enforcement: System checks expenses against company policies for compliance (e.g., spending limits, allowed categories).
6. Approval Workflow: Multi-level approval process for submitted expense reports, including manager and finance review.
7. Per Diem and Mileage Calculation: Automatic calculation of per diem allowances and mileage reimbursements based on company rules.
8. Multi-Currency and Tax Handling: Support for expenses in multiple currencies and calculation of applicable taxes (VAT, GST, etc.).
9. Project and Cost Center Allocation: Allocate expenses to specific projects, departments, or cost centers for accurate financial tracking.
10. Audit and Fraud Detection: Automated and manual audit processes to flag suspicious or non-compliant expenses.
11. Integration with Accounts Payable: Approved expenses are processed for reimbursement through the Accounts Payable module.
12. Cash Advance Requests and Settlement: Employees request cash advances and settle them against incurred expenses.
13. Delegate Expense Entry: Allow assistants or delegates to enter expenses on behalf of other employees.
14. Expense Report Resubmission and Correction: Employees can resubmit corrected expense reports after rejection or audit queries.
15. Expense Analytics and Reporting: Dashboards and reports for spend analysis, policy violations, reimbursement trends, and audit outcomes.
16. Automated Duplicate Detection: System flags potential duplicate expenses or receipts for review.
17. Integration with Travel Booking Systems: Sync travel bookings with expense reports for seamless reconciliation.
18. Expense Category Management: Define and manage custom expense categories and subcategories.
19. Notification and Alerts: Automated notifications for pending approvals, policy violations, or missing receipts.
20. Role-Based Access and Security: Control access to expense data and actions based on user roles (employee, manager, auditor, finance).

This is now the most comprehensive set of requirements I’ve seen associated with an ERP project- 120% more than I had seen on an average real life ERP project.

The timings are then “off the charts” by comparison. This took me 10 minutes to create a list that could have taken 27 hours of effort which, on the face of it, is 162 times more productive (27 divided by 0.16666). To validate this number, I need to check that I’m being as honest as I can be with the comparison. Yes, it would take five people five hours to get the same result, However, one of the benefits of the face-to-face workshop would be that everybody would have been involved in the synthesis of the requirements and will have verified them within the session. So, in order to verify the CSN produced requirements, I’m thinking we need 1 hour of the four people’s time back to buy into the above list of 20 items. This gives me a ‘true’ ROI of (27 divided by 4.16666). From which I conclude that CSN is a factor of 6.5 times more efficient at deriving business requirements which is certainly a quantifiable benefit of using CSN (the second of the two problems we set out to solve).

In addition, we have also solved the first problem by stating the requirements of a Enterprise Class ERP system for Expenses Management- and we’ve done it 6.5 times more efficiently. The next steps here is to undertake a piece of work to document the other areas of AP as well as Accounts Receivable, Fixed Assets, General Ledger, Project Management etc so that we have a comprehensive catalogue of a full set of client needs.

Follow on work for CSN

CSN also indicated it would be able to help me with Expenses Management for process mapping, test management and other aspects of the project lifecycle which I will explore in future articles.

Great to spend time with a world class University today to go through the experiences of getting ERP to the Cloud.

Embarking on an Oracle ERP implementation can be one of the most challenging experiences in a professional career. These projects are often large in scope, with complex integrations, tight deadlines, and a wide range of stakeholders. For individuals on the project team, the sheer volume of tasks, dependencies, and shifting priorities can feel overwhelming. However, with the right approach and tools like JIRA, you can regain control of your workload and navigate the chaos more effectively.

Why Oracle ERP Projects Feel Overwhelming:

1. Multifaceted Scope – Oracle ERP projects typically span financials, supply chain, HR, and more. Each module has its own requirements and timelines.
2. Tight Interdependencies – A delay in one stream often causes a knock-on effect elsewhere, adding pressure and stress.
3. Continuous Change – Stakeholders frequently update requirements, meaning priorities can shift overnight.
4. High Documentation Load – Testing scripts, configuration documents, and integration mappings can quickly pile up.

Leveraging JIRA to Manage Your Individual Workload

While JIRA is often used for team-level project management, it can be a powerful personal productivity tool in large ERP programmes. Here are key features and strategies:

1. Personal Boards and Filters
   • Create a Kanban board filtered to only show your tasks. This gives you a clear at-a-glance view of what’s in progress, blocked, and completed.
   • Use swimlanes to split tasks by module or priority, helping you focus on the most critical items first.
2. Sub-Tasks for Complex Tasks
   • Break down major deliverables like a configuration pack or a test cycle into sub-tasks. Tracking these smaller steps reduces mental clutter and gives a sense of progress as they are completed.
3. Custom Dashboards
   • Set up a personal dashboard to track items assigned to you, upcoming deadlines, and blockers.
   • Include charts for workload distribution and priority levels to better plan your day.

1. Labels and Components for Clarity
   • Tag your tasks with labels such as “Finance”, “Integration”, or “Testing” so you can quickly filter and focus on related work. Personally, I’m not a fan of labels. Labels can cause problems because the individual users can add, for example, #Accounts Receivable; #Account Receivables; #AR etc. When building a dashboard or a filer then spelling mistakes in the labels result in tickets being missed. A more reliable way is to create a custom field with a series of specific values that the user selects from
2. Automation for Notifications
   • Use JIRA automation rules to notify you when a dependent task is completed or a blocker is resolved.
   • This prevents constantly checking for updates and reduces the risk of tasks slipping through the cracks.
3. Time Tracking and Estimation
   • Logging time and setting realistic estimates can help you visualise workload and communicate capacity to your project manager.

Bringing It Together

An Oracle ERP project doesn’t get less complex just because you’re organised—but your experience of it can improve dramatically. By leveraging JIRA not just as a project-level tool but as a personal task manager, you can:

• Prioritise with clarity
• Break down intimidating deliverables
• Track progress without losing sight of dependencies

In the midst of an overwhelming ERP programme, JIRA’s personal boards, dashboards, and automation features can give you the breathing room to stay productive and maintain your sanity.

Implementing an Oracle ERP (Enterprise Resource Planning) system is no small feat. It demands meticulous planning, cross-departmental collaboration, and the ability to navigate complex challenges. While the primary aim is to streamline operations and integrate data across the organisation, the process itself is a powerful lesson in problem solving. The principles and techniques used to successfully deploy an ERP system can be applied to a wide array of other problems, both in business and in life.

1. Break Down Complex Problems into Manageable Parts

One of the first lessons from ERP implementation is that large, complex problems are best tackled in smaller, structured components. Oracle ERP systems touch finance, supply chain, HR, and more. Attempting to handle all configurations and integrations in one go is a recipe for chaos. Project teams often divide the implementation into modules or phases, focusing on one area at a time.

Lesson for broader problem solving: Any daunting issue can be decomposed into actionable segments. Whether you are developing a new product or resolving a team conflict, clearly defining the individual moving pieces makes progress more achievable and less overwhelming.

2. Invest in Thorough Preparation and Planning

ERP projects succeed or fail in the planning phase. Organisations that rush into configuration without mapping out existing processes, data flows, and future requirements frequently hit roadblocks. Successful implementations involve months of requirement gathering, stakeholder interviews, and process documentation before the first line of code is touched.

Lesson for broader problem solving: Preparation is not wasted time—it is the foundation of effective problem solving. Before leaping to solutions, take the time to understand the landscape, gather data, and identify potential risks.

3. Engage Stakeholders Early and Often

Oracle ERP implementations affect nearly every part of an organisation, which means ignoring stakeholders leads to resistance, errors, and rework. High-performing project teams involve finance managers, HR leads, and operations staff from day one, ensuring that the system will serve their needs and that they feel ownership of the final result.

Lesson for broader problem solving: Problems rarely sit in isolation. Whether in business or community initiatives, involving all relevant parties from the outset reduces friction, surfaces blind spots, and fosters solutions that are more widely accepted.

4. Embrace Iteration and Testing

ERP systems cannot simply be installed and left to run. They require rigorous testing in sandbox environments, followed by adjustments based on user feedback. This iterative approach allows teams to catch errors early and refine configurations before full go-live.

Lesson for broader problem solving: Iterative problem solving—testing, learning, and adjusting—is far more effective than seeking a perfect solution on the first attempt. In any project, creating a feedback loop and being willing to adapt is key to long-term success.

5. Anticipate Resistance and Manage Change

Even the most technically flawless Oracle ERP implementation can falter if users are resistant to change. People are naturally inclined towards familiar systems and routines. Successful ERP projects incorporate change management: clear communication, regular updates, training sessions, and support structures that help staff transition smoothly.

Lesson for broader problem solving: Human behaviour is often the hardest part of any problem to manage. Solutions must account not only for the technical or logical aspects but also for the emotional and cultural dimensions of change.

6. Document and Learn from the Process

ERP implementations generate extensive documentation—process maps, training manuals, and lessons learned. This not only supports current operations but also provides a reference for future challenges.

Lesson for broader problem solving: Documenting your findings, decisions, and results reinforces learning and aids continuous improvement. When tackling other complex problems, keeping clear records of what worked and what didn’t accelerates progress next time.

7. Celebrate Milestones and Recognise Success

Large implementations can span months or even years. Recognising achievements along the way—completing data migration, finishing a round of testing, or going live with a new module—keeps morale high and reinforces the team’s commitment.

Lesson for broader problem solving: Breaking down challenges into smaller wins and acknowledging progress helps maintain momentum and motivation, whatever the problem at hand.

Applying ERP Lessons to Everyday Problem Solving

The implementation of an Oracle ERP system is a masterclass in structured, collaborative problem solving. By breaking down complexity, preparing thoroughly, involving stakeholders, iterating solutions, managing change, documenting lessons, and celebrating progress, organisations develop disciplines that extend far beyond software deployment.

Whether you are reinventing a business process, designing a new product, or navigating personal challenges, these same principles can guide you to clearer thinking, stronger actions, and more sustainable outcomes.

Complex problems may feel unique, but the methods for solving them are universal—and an ERP system is proof that even the most intricate challenges can be conquered with the right approach.

70% of ERP projects fail; 25% of them fail catastrophically (L. Clark, The Register 2025). Those figures are alarming enough but it gets worse when you consider the consequences. If we consider a “mild failure” then we could expect to see a two to six month over run which, assuming a cost expenditure of $1m/month then this equates to between $2m and $6m cost over run. I would also advise clients to put aside enough funds for a six month over run- “just in case”. If you consider Birmingham City Council to be at the other end of the spectrum then we are talking about a project that planned to cost £20m actually costing nearer £170m or eight and a half times the original cost (L. Clark, The Register 2025).

The good news is that there a relatively small number of things that can go wrong and all are avoidable. At the heart of the project are four pillars that we need to manage:

• The timeline
• The scope which includes the benefits and requirements catalogue
• The testing of the system to ensure we go-live with quality built in
• The resources involved (project team; end users and suppliers)

Let’s consider the top 3 threats to each in turn:

Timescales

The project plan forecasts when the new system will go-live. At the most granular level, it tells us what tasks need to be accomplished each day and the milestones tell us whether we are on track or not. The go-live itself is the culmination of a large number of interlocking activities that are highly dependent on other activities. Should something change then the dates can move- sometimes for the better but often for the worse.

The top 3 risks to manage against the timeline are: 

• Underestimating how long each activity takes. This occurs because people can lack experience of the delivery of such projects and simply get their forecast wrong. In an ERP project, a task that should take two days can often take five to ten days to ensure that everybody who needs to be involved in the task has been consulted. Building the correct review times into such activities is a key mitigation

• The dependencies themselves are key. Often dependencies are missed and key activities or even phases of work such as End User Testing can’t start because a key pre-cursor wasn’t identified. This can lead to unnecessary stand still on a project that can be burning $1m/month

• Change to the scope of the project is inevitable. On an ERP project we might anticipate 40-60 such requests for change. Not all of these result in an increase in cost but they can affect the timeline. It is crucial that any changes to the scope are considered before being agreed to. The good news is that implementing a robust project change management approach is fairly simple to do- but it needs to be done early and everybody involved in the project needs to be onboard and involved with this process

Scope

ERP projects are not cheap and it is likely that a business case was needed to be written and approved to release the investment funds required. The business case will have highlighted the benefits of the project which, hopefully, will include tangible financial savings to the organisation. Alongside the business case will be the need for a clear definition of scope of the project which should include a catalogue of business requirements.

The top 3 risks to manage against the scope are:

• Not realising the benefits. This often occurs because there are gaps in the requirements catalogue and/or that the requirements are not traced back to the benefits. Discussed above is the need to manage change of scope and a key failing of a project during the design or testing phase is to descope a requirement without understand the impact it could have on the benefits that have been signed up to.

• Finance ERP systems are renowned for needing a large number of technical integrations with other systems. These can be “up stream” systems that have inbound interfaces into the ERP system or “down stream” systems that have outbound interfaces from the ERP system. The technical integrations that need a disproportionate amount of attention are the systems that have “two way” integrations. The most common of these is if there a separate Customer Experience System (“CX”) that sits outside of the ERP platform. Such “two way” integrations are not just twice the risk of other “one way” integrations but more likely to be four or eight times more risky.

• Focusing on the technology and not the business process itself. Yes, an ERP project is a huge technical undertaking but not understanding the impact the new system can have on the underlying process can often lead to business disruption after go-live

Quality

Testing the system is key. Technical Interfaces are rigorously tested as part of the System Integration Testing (“SIT”) and User Acceptance Testing (“UAT”) is there to ensure that each business requirement is met at that the system supports the end-to-end business process. The ERP system itself will have been thoroughly tested by the software provider so we have a look a little deeper at where the quality threats come from.

The time 3 risks to manage against the quality of the system are:

• Data Migration. ERP systems have robust workflows to allow data to be created (e.g. setting up a new supplier). There is then a technical term called “referential integrity” to ensure that data from one part of the system corrects correctly to data in another part of the system. An example being when a Purchase Order is created against the supplier that we also set-up in the system. This flow continues with the Goods Receipt Notice; the Purchase Invoices and the payment notification. If all the data was created directly in the ERP system then we would have a much simpler project. However, at any given point, there will be open Purchase Orders; goods in transit; good receipted but not paid for etc etc. In practice, we are required on an ERP project to migrate different types of data from the old system to the new system. We now have the added complexity, for examples, of testing whether we can create a new Purchase Order in the new system linked to a supplier’s details that have been migrated over. It is critical that the migrated data used for UAT is super clean (Circa 95% correct). Getting data migration right is extremely tricky and should have a project work stream all to itself.

• Reporting requirements are not met at go-live. ERP systems come with a large number of reports and dashboards out-of-the box. However, every organisation runs their processes slightly differently. This results in reports often needing to be amended or new ones created. New ERP systems bring new ways of visualising the data and this often reduced the number of reports required. It wouldn’t be unusual to have 600 reports on the old system that become whittled down to just 60 reports on the new system without losing anything. This is quite a transformation and getting this right should have a project work stream all to itself 

• Product defects in the cloud based system. ERP systems are Common Off-the-Shelf (“COTS”) software packages. If the software selection has gone according to plan then there should be between 85-90% match of the business requirements with the out-of-the-box system. However, there are no guarantees that the new software will be glitch free. At the time of writing, software providers are busy creating quarterly upgrades with new Artificial Intelligence features. The software doesn’t stand still and there is always a risk that new features dont work for your given use cases or that these new features have had an unintended consequence on existing features. Such issues are rare but do need to be managed with the software supplier to ensure that there are no unnecessary delay. Having a representative of the software provider on the project board is a key mitigation.

Resource

ERP projects not only need an army of people (which is where the costs come from) but also highly skilled people – include existing people in the organisation who have a deep understanding of how the processes work across the organisation.

The time 3 risks to manage against the project resources are:

• Resource availability. This can manifest itself in a number of ways. For example, there maybe a certain skill that is an organisation doesn’t have a lot of (e.g. Sales & Purchase Taxation processing). Assume that there is only one person in the organisation with this skill and they have a busy day job as well as needing to be available for the project. Also, the project Subject Matter Experts (“SMEs”) are fully utilised on the projects and there are pinch points on their time across the project. This is particularly a problem if some activities become delayed and the original resource profile changes. For example, an SME might need to work on the review of training material at the same time as supporting SIT execution and UAT preparation. These activities creates a very timetabled schedule and problems with any of these work streams can knock the timetable out.

• Resistance to change. ERP systems are not replaced very often- as much as once every 20 years. So people across the organisation get very familiar with their ways of working. The pain points that we are trying to get rid of in the old system have simply become accepted workarounds over the years. Managing the business change should have a dedicated project work stream to manage this risk.

• System integrator performance issues. The System Integrator market place is exceptionally mature with each of them having well refined accelerators in order to get the new ERP system delivered as speedily as possible. However, these methodologies are only as good as the people using them. System Integrators need people with a plethora of skills such as ERP technical skills; good at people management; an understanding of the underlying industry sector for the implementation; project management disciplines as well as a working knowledge of the system integrator’s accelerator product. It is key that there is an escalation process in place with the system integrator to ensure everything runs smoothly and that issues are dealt with quickly and effectively. 

Background

One of the benefits of working in Higher Education is that you are surrounded by academics who are always looking for data to analyse. An ERP implementation in a University provides much data for academics to chew over, analyse, summarise and publish to the wider community. 

You would think that everything that could be said about ERP implementations was said long ago. However, this is a review of a paper from as recent as 2024 from two academics (Kevry Ramdany and Asniati Bahari) in the Faculty of Economics and Business at the Universitas Andalas in Indonesia. They looked at a single ERP project in West Sumatra and used a research technique of interviewing key stakeholders to draw out the key themes that shed light on Digital Transformation.

Academic papers have a strict layout and way of doing things that can often result in a difficult read. However, I aim to use my academic background to help cut through the density and to present the key pieces of information that will help you with your own digital transformation

What does the paper say?

The first two findings are not surprising:

1. Plan carefully and prepare (including the selection of modules you want to use, outreach and training)
2. Reduce risk through a phased approach (configuration, data migration, sequential launching)

One aspect of the paper’s findings is the early socialisation of the system through seminars, workshops and presentations. From my own experience this can be a tricky one to pull off. In the early days of the project lifecycle you don’t have all the key features working and, without migrated data, the experience of the system can be less than compelling. However, I’m an advocate of starting to tell the story early and demonstrate how intuitive modern systems are. Ask yourself, “when in the journey will we be getting in front of schools, faculties and departments to tell the story of our ERP journey?”

Challenges faced

The paper calls out two key challenges faced by this particular project

1. Resistance to change
2. Budget limitations

Regarding resistance to change, the key point that the paper makes is the lack of technical skills among staff and lecturers and that comprehensive training is critical.

For budgetary limitations, the paper specifically quotes one of the participants who took part in the research:
“After implementation, universities must consider the costs of maintaining the ERP system, including technical support, software updates, and system security. These costs may vary depending on the complexity of the system.”

It is certainly true in my experience that many projects focus on the cost of implementation and often do not factor in the required cost to manage ongoing change. Ask yourself, “have we set aside enough in the business case for post go-live support?”

Factors for Successful ERP Implementation

The paper focuses on 3 key success factors for people to take into consideration:

1. Management support (including the allocation of adequate resources for the project and active support to overcome obstacles during implementation). The paper also references the need for project leadership to being experienced in the relevant technology as well as an understanding of University operations.
2. User Engagement (including serious consideration from end users in the planning and implementation process)
3. Careful planning stating that “a detailed implementation roadmap is essential”. This helps with regular reviews of milestones and budgetary expenditure.

Impact of ERP implementation on Operational Efficiency and Service Quality

The paper looks at the the success of the project through interviews finding, for example, “a faster and more structured registration and payment process”. I know we often seek to have a business case with benefits that are quantitative and cashable. However, I would suggest that the starting point for any such project is the qualitative approach that we see in this paper and many others:

1. What pain points with this project remove?
2. After go-live, simply ask the question of the functional managers (accounts receivable, accounts payable, collections, cash management, fixed assets, general ledger) what service improvements are we seeing?

The paper concludes with the key points that becomes your key take-aways:

1. Plan carefully and prepare for adoption (module assessment, outreach and training)
2. Implementation should be phased to help manage risk
3. You will see a positive impact on operational efficiency and service quality through process automative, data Integration and access to information
4. Adopt a strong communicative approach to overcome resistance to change
5. Invest in comprehensive training on how to use the system (referred to as “technical” training)
6. Effective and transparent budget management is a priority with sufficient resources both for implementation and long term maintenance
7. Plan to continuously evaluate and monitor the system after go-live

Formal Reference of the paper

Ramdany, K., & Bahari, A. (2024). Digital Transformation in Higher Education through the Implementation of Enterprise Resource Planning. JOURNAL OF APPLIED MANAGERIAL ACCOUNTING, 8(2), 310–319. https://doi.org/10.30871/jama.v8i2.8454

Link to the actual paper

The paper can be found through Google scholar at no cost and is available at the Journal of Applied Managerial Accounting.

https://jurnal.polibatam.ac.id/index.php/JAMA/article/view/8454

With the keywords

Digital Transformation, Higher Education, Enterprise Resource Planning (ERP), and ERP Implementation

This article is for you if…

..you manage technology and are involved in a project or programme and you are afraid to ask ‘who is suppose to be doing what?’

Or

…if you are regularly involved in technology change projects and you need a resource to share with your clients or internal customers because they keep asking you questions that are better answered by somebody else in the project team.

References

https://sfia-online.org/en

Background

If you run a function that is about to or is going through a significant amount of change

Change either happens iteratively and continually or in a big step such as through a project or a programme. You are probably involved in continual change all the time either helping people develop their skills, tweaking a process or procedure and making small changes to reports or the systems that you use. However, when a project or programme comes along it usually accompanied by help from outside the function or organisation. 

Technology change projects can bring with them a bewildering number of people that have opaque job titles who seem to know what they are doing and you are probably wanting to ask “what exactly is it you do?”. This article helps you understand exactly what each job is designed to do and who you need to go to so you can find answers to your questions without being given the runaround. It explains who is on the hook for what and what outputs you can expect from all of these strange people that have invaded your space.

If you help deliver change

If you are involved in projects and programmes all the time you probably take for granted what everybody does. However, it recently came to me as a shock that one of my senior clients wasn’t aware of the differences in the key roles. So, if you are involved in the delivery of technology change then you can use this article as a resource to share upfront to demystify what it is you do.

How this article helps

The good news is that there is a really helpful online resource that is free for you to access for your personal knowledge, that is well laid out and can help you cut to the chase. What is even more surprising is that most people involved with technology don’t know that this resource exists.

The bad news is that we often see ‘hybrid roles’ where people describe themselves as having a mixture of skills but we will get to this later.

The theory

The online resource is the Skills Framework for the Information Age (“SFIA”) and is the management system that you probably haven’t heard of. It defines the skills and competencies required by people who manage and protect the data and technology that power the digital world (SFIA Website). The people who are aware of it treat it with great affection and often call it ‘Sofia” or even “Sophie”. It is a relatively modern management system introduced in 2000 but is already on its 8th version. 

So how does SFIA it work? 

SFIA has a series of skills (think of them as job families) – for example, Information Security. For each skill, there is a ladder of seven levels starting at level 1, the lowest, going up to level 7, the highest. The levels are summarised as:

SFIA describes not only the autonomy but also the level of influence for each level as well as the complexity, business skills needed, and the knowledge required to perform at that level.

SFIA also provides guidance where certain levels are not normally seen within a job family. For example, Level 1 and Level 2 are rarely seen with the Information Security skill due to the complexity and skills required. Whereas Levels 6 and 7 are not normally seen for the Incident Management skill but levels 1 to 5 are.

For each skill there are some guidance notes and it explains what you can expect from each level. There is also a useful list of links to related skills. For example, the related skills for project management are listed as:

It is important to note that SFIA lists all aspects of technology that includes business change, data science, learning and education, selling, product management, support as well as core Information Technology skills.

Project and Programme roles that you can expect to see that are covered by SFIA…

The content below is to help you understand in practical terms what you can expect from the key roles you are likely to encounter. You can then use the SFIA material for more detail.

Project Management

The Project Manager is the ‘Quarterback’. They might not score many points but they make all the play. However, in projects the project manager not only drives the project forward but also drives the defensive play as well. They make milestones happen (the ‘points’) and they are on top of the risks and have plans in place to ensure risks are minimised or don’t actually materialise (the ‘defence’)

Even at the lowest SFIA level (level 4), the project manager defines, documents and executes the project. At level 4, the projects are small or even sub-projects and level 6 is reserved for complex projects. Level 7 isn’t usually a project manager role but somebody who sets the governance up for projects within an organisation or who authorises large-scale projects. However, at level 7 you can expect somebody will this level of skill to lead strategic, high impact, high risk projects.

What you can expect from the project manager?

• That the project is delivered to time, to budget and to scope/quality. 

The project manager will often refer to their triangle of timescales, cost and scope. They are seen to only be able to manage these three variables. 

What outputs will the project manager own?

• a plan! This needs to be a series of activities that has start dates, end dates, milestones and named resources.

• highlight reports

• a list of Assumptions; the Risk register; an Issues log and a table of Dependencies. This is often grouped together and referred to as an ARID

• a cost model

Details of Project Management in SFIA can be found here.

Different types of project manager

Good project manages control their three variables intently. They will own the timescale, be meticulous about the scope and be heavily involved in the resourcing to ensure that the project gets done. There is a whole toolkit for managing change that a good project manage won’t hesitate to invoke should something change. 

Good project managers keep the risk register simple and proactively manage the risks.

Exceptional project managers will work with stakeholders to ensure that no change comes as a surprise and provide costed options to the person accountable for the project in advance. The exceptional project manager will work with the sponsor/owner of the project sufficiently far ahead so that options are realistic and credible and avoid decisions being an inevitability.

Blame the project manager if…

• the project is delayed
• the project is over budget
• the project doesn’t deliver the features or benefits

In particular, the project manager is at fault if there are any surprises with the timescales, costs or scope. Ultimately, it is the project sponsor that is accountable but the project manager will be controlling the timescales, budget and scope and managing change.

Projects are remembered for being late, over budget or put something in place that is of poor quality.

If you want the change to be successful, ask the project manger about…

• resourcing
• whether the overall risk score is coming down
• what are the chances of hitting the next milestone

Things to look out for…

• Project managers can be light touch. It is common to have project managers on the project only one, two or three days a week.

Business Analysis (or “Business Situation Analysis”; “Benefits Management’ and “Requirements Definition and management” in SFIA)

A business analyst is used to investigate a particular business situation that might be a problem or opportunity. The skill level involved of the individual is linked to the complexity of the problem and the level of involvement of stakeholders. The SFIA model is quite tight for Business Analysis and only goes from level 3 to 6. 

What outputs will the business analyst own?

• problem statements
• business requirements
• recommendations
• use cases
• user stories
• value chains
• ‘as is’ process maps
• ‘to be’ process maps
• pain points

Business Situation Analysis in SFIA can be found here , Benefits Management can be found here and Requirements definition and management can be found here.

Sometimes the business analyst will be involved in scoping the testing. They can also be involved in writing a business case – especially the benefits section.

“Pure play” business analysts are rare. They have a wide range of techniques and tools to get to the bottom of a problem or to be able to capture the benefits of an opportunity. Most sponsors of projects or programmes expect more outputs from a business analyst, however, most sponsors also significantly underestimate the effort and skills required to determine business requirements for a solution or the skills required to actually measure the impact of a problem.

Different types of business analysts

Good Business Analysts will work hard to ensure that the requirements catalogue is complete and create it in a timely fashion. Good business analysts will avoid ‘analysis paralysis’ and excessive delays. 

An exceptional business analyst will be able to articulate benefits as quantifiable, financial and cashable.

Blame the business analyst if…

• requirements are missing (often not found until User Acceptance Testing and can cause cost over runs because of delays)
• ‘as is’ processes that haven’t been discovered
• recommendations are not implementable

If you want the change to be successful, ask the business analyst about..

• reporting requirements
• integration requirements
• data migration requirements
• how benefits are being measured
• threats to timescales, cost and scope

Things to look out for…

• the term ‘Business analyst’ covers a multitude of skills (3 across SFIA). Good ones are worth their weight in gold and most don’t command a high salary or day rate because they only cover a small set of the skills. Good ones are worth as much as project managers but are often seen as subservient. Try to determine which aspects of business analysis your business analysts are actually covering as it might leave gaps in your expectations.

Programme Management

Projects are common; programmes are rare because they are not understood. In SFIA, Programme management only exists at level 6 and 7 and so levels 4 and 5 at project management have no equivalent.

So what is the difference between projects and programmes? Put simply,..

…a projects delivers a single asset that is a tangible output through a unique and temporary organisation. They have clearly defined scope, start points and end points. Projects can be as short as 3 months and can be up to 2 years..

…a programme delivers benefits and the deliverables maybe unclear at the start and the scope can change as the programme unfolds but ultimately are judged on the benefits (increased revenue; increased customer satisfaction etc). Programmes almost always have multiple projects (the “programme portfolio”) delivering separate assets and programme usually last start at 2 years and can go on for as long as 4 years and upwards

So why is there confusion? There is a lot of overlap in terminology. For example, a project will have a business case that articulates the benefits (“programme speak”). Projects can have multiple work streams which can often be referred to as separate projects that contribute to the overall single asset. For example, a new IT system might have a reporting project; data migration project; integrations project…however, these all come together at the same point in time to create the new asset. This leads to a portfolio of projects (again, “programme speak”)

True programmes are rare. However, ‘big’ projects might be termed as programmes to attract high calibre (“Level 6”) project managers and used to justify higher financial reward. Very few organisations have three levels of banding for project managers (which SFIA supports) but do refer to job descriptions as:

• project managers
• senior project managers
• programme managers

Programme managers have overall accountability for each project

Programme management in SFIA can be found here.

This leaves nowhere to go when there is a genuine programme which is why sometimes the term ‘programme director’ is used to describe the person is actually running a true programme. 

Blame the programme manager if…

• benefits aren’t being realised
• benefits aren’t being tracked as each project is delivered

If you want the change to be successful, ask the programme manager about..

• benefits tracking
• the target operating model
• threats to benefits

Things to look out for…

Programme managers often have project managers to support them. I’ve been a programme manager that had 22 projects in its portfolio and we had 4 project managers that handled 4 projects each at any one time. 

Project Management Office/PMO (or “Portfolio, Programme and Project Support” in SFIA)

A good project manager will set the tools up so that tracking, recording, reporting and exception handling has minimum administration. However, big projects and every programme starts to get too big for an individual to control and they need help. This is where the PMO comes in.

A PMO can either be set-up specifically for a project or programme or can lean on a central PMO within an organisation. 

What outputs will the PMO be responsible for (if there isn’t a PMO then this comes down to the project manager)…

• Reporting packs that include highlight reports, risk updates, milestone schedules
• scheduling workshops
• reducing admin for the project team
• tooling (e.g. timesheets)
• Portfolio, Programme and Project Support in SFIA can be found here.

Different types of PMO:

• Weather station: report status with an accurate short range forecast and somewhat variable long range forecast
• Air traffic control: they don’t fly the planes but do control when a plane (or project) can take off (project start-up) or land (project closedown)
• Resource pool: provide project managers, business analysts, project support staff

Blame the PMO (or project manager if there isn’t a PMO) if…

• reporting packs are late or inconsistent 
• actions are overdue
• risks aren’t being managed
• the project team complain that there is too much admin
• decisions are not being taken on time

If you want the change to be successful, ask the PMO (or project manger if there isn’t a PMO) about..

• benefits tracking
• the target operating model
• threats to benefits

Things to look out for…

• if there isn’t a PMO and the issues highlighted above are starting to materialise then it is time to set-up a PMO. The project manager might not welcome this because it maybe seen that they are failing but if you are the sponsor of the project then you are accountable and need to act
• What type of PMO you actually have. Some will step in without asking if projects are off track, some will identify interventions and make recommendations and the weather stations will just tell you it is going to rain without telling you what to do about it.

Technical Lead (“Solution Architecture” in SFIA)

It is often assumed that the supplier will define what the solution looks like. However, rarely will a solution exist in isolation. Technical solutions, even cloud based products, need to be integrated with other technical products and the technical infrastructure of the organisation- “Solution architecture”. 

In addition, solutions need to be kept simple (using configuration not customisation; “No code/low code not pro-code”) and there needs to be a technical authority to oversee what the supplier is proposing at every turn- again, “solution architecture”.

It is possible that somebody from the organisation’s IT team can be assigned to the project but this person needs the technical understanding of the solution that the supplier is providing as well as an understanding of the technical landscape of the organisation. Very few people have skills in both.

What outputs will the technical lead be responsible for…

• Ultimately, the quality of the technical solution. Think of this as the supplier will deliver a washing machine but the technical lead is responsible for plumbing it in and wiring it up
• …a sustainable solution that the in-house team can manage once the supplier and project team have been disbanded and moved on

Different types of technical lead:

Information Technology covers a broad spectrum and solution architects typically from a specific background and so have a lean towards one of a number of areas

• ‘data’ such as database managers or developers
• ‘hardware’ such as servers and storage
• ‘software’ such as coding and development
• security’ such as information security analysts

Blame the technical lead if…

• The solution doesn’t work
• The users are frustrated with the user experience (e.g. too many clicks)
•  There are data protection/information governance issues that delay implementation

If you want the change to be successful, ask the technical lead about..

• How technical decisions will be made?
• Where is customisation/pro-code unavoidable?
• What are the key technical risks?
• Which other organisations have successfully implemented what we are attempting (if any)

Things to look out for…

• Try to find out what the technical lead’s background is and what they lean towards. For example, a software background might make them particularly skilled in the areas where coding is required (such as integration).
• The organisation may have an Enterprise Architecture function or individual who can provide standards and policies but is unlikely to be able to dedicate the time required in order to be involved in the number of design workshops, attend daily stand-ups and scrutinise the testing.

Hybrid roles

There is a lot of cross over in the project and programme management world. Things to look out for include:

• “PM/BA” (a Project manager and Business Analysis combined). This can be sometimes justified if a light touch project manager is required and the business process is relatively simple and not changing. In this instance you can expect, for example, the Project Manager to create the requirements catalogue
• Technical Project Manager (a project manager combined with a solution architect).
• Project Manager/PMO. This is common on smaller projects where you have an experienced project manager. However, smaller projects with a level 4 project manager are often supported by a central PMO.