Welcome to part 2 of our 5 part series exploring the evolution of Project Analytics and how it’s transforming the performance and outcome of major projects initiatives.
In this article, we explore some use cases and best practices for getting started with project analytics.
Closing the Project Analytics ‘Imagination Gap’
“We need a critical mass of people who have the desire and the skills to make change happen at a personal and project level. Only with that critical mass can we change the sector.”
Gareth Parkes, Head of Data & Analytics at Sir Robert McAlpine, DataIQ interview
In the early days of your project analytics initiative, one of your primary goals will be to bring together the data and process communities.
On one side, you have those with an in-depth knowledge of the business process and can imagine the art of the possible with improved project analytics, and on the other side, you have the data team.
To succeed, you need to bridge this gap and create a unified team.
Moving data out of the backroom
Within major projects, the data function can often be seen as a backroom function and hence somewhat undervalued by the organisation.
Where we’ve observed project analytics success, the cultural mindset around data has shifted.
Project leadership, in particular, have recognised the incredible value that the right mix of data skills and technology can deliver for better decision-making and operational outcomes.
Creating a coalition of process and data expertise
To close the project analytics ‘imagination gap’, you’ll need to align those with the vision for project analytics (those who typically understand project processes intimately) and the internal data experts who understand project data and systems at a granular level.
Whilst it’s admirable to have a grand vision of ‘shooting for the moon’ with Artificial Intelligence and Machine Learning, we recommend getting started by building a cohesive team of process and data experts to focus on some impactful (and achievable) short term use cases.
What data skills will you need?
You clearly need to bring in some extra data professionals onto your project analytics initiative, but what roles are required?
Data Analysts:
These are the ‘workhorses’ of any data-intensive program. You will need to ensure that your data analysts have the requisite skills because the data analyst role can vary across industries.
The Gov.UK website provides a good overview of a Data Analyst Job Description:
- Apply tools and techniques for data analysis and data visualisation (including the use of business information tools)
- Identify, collect and migrate data to and from a range of systems
- Manage, clean, abstract and aggregate data alongside a range of analytical studies on that data
- Manipulate and link different data sets
- Summarise and present data and conclusions in the most appropriate format for users
Data Engineers:
It’s fair to say that large capital programs are often more used to working with construction engineers than data engineers, but data engineers will become a critical aspect of your project analytics success.
Data engineers are similar to traditional engineers in that they translate the architectural vision into a series of enabling structures. For example, they build ‘bridges’ between disparate data systems, allowing for the flow of data into your reporting and analytics environment.
Here is a sample of the standard Gov.UK job description that may help when looking for Data Engineers internally:
- Implement data flows to connect operational systems, data for analytics and business intelligence (BI) systems
- Document source-to-target mappings
- Re-engineer manual data flows to enable scaling and repeatable use
- Support the build of data streaming systems
- Write ETL scripts and code to make sure the ETL process performs optimally
- Develop business intelligence reports that can be re-used
- Build accessible data for analysis
Data engineers are some of the most undervalued, yet critical team members. A good data engineer is essential if you are to unlock the ability of your data analysts and data scientists.
Data/Solution Architects:
Just as you would with a construction project, you’ll need a data/solution architect to translate the business requirements into a series of architectural frameworks that can be passed on to the data engineers and data analysts for implementation.
The architecture role will require someone to act as a conduit between IT, the data team, and of course, the business stakeholders.
The challenge is that, at a project level, you won’t necessarily need this resource for long. They are typically a centrally provided resource, released to projects as required.
This type of ‘hub and spoke’ resourcing arrangement requires a strong link between the centre (and any corporate work) and the more pressing needs of projects.
Data Scientists:
There is often a desire to onboard data scientists before the appropriate data architecture and platforms are in place. The danger is that if your project lacks data engineers, your data scientists won’t have any data to work with.
Without data engineers, your data scientists will spend far too much time dealing with ‘data plumbing and cleansing’ issues instead of what they were hired for – delivering insights that drive impactful business outcomes.
Note: Some data roles are rarely found on large capital programs, so you may need to bring in some central or external expertise to bolster your team initially.
There are no silver bullets
It’s important to realise how non-trivial these project analytics initiatives are. You can’t expect to overlay some data visualisation and reporting tools on top of an existing disparate landscape of project applications and hope to crack the problem in one go.
Few organisations can deliver a seamless project analytics initiative right from the start; the industry is not yet at that level of maturity. Even if your organisation has matured its approach to project analytics, you may find your clients and supply chain are lagging some way behind.
But as you’ll learn in this article series, several organisations are making giant leaps forward when the necessary platforms, approach and staff are brought together.
These organisations are shining a light on the way forward.
Creating the business use case
Many organisations struggle to articulate what they want from project analytics, making it hard to define a viable business use case.
Part of the reason is that organisations don’t understand the costs associated with poor quality data and processing. They may sense that decision-making and planning are impaired, but calculating the impact and cost due to poor data can be notoriously difficult.
Of course, this struggle to calculate the cost and benefit is perfectly understandable. It’s difficult to know the art of the possible if your organisation is not familiar with the next generation of project analytics approaches.
Start with a reporting review
To help guide your initial use cases, our advice is to start by reviewing your current reporting approach because you may already be doing a good job in some key areas.
During your review, don’t get too focused on evaluating the ‘bells and whistles’ of existing reporting tools. Instead, use the study to understand the management decisions your current reports support and inform.
Take time to review the maturity and quality of your existing reporting approach by gathering evidence such as:
- How well are key information requirements monitored today?
- How easy is it to perform a more in-depth, ‘second-order’ analysis of any questions that arise from a report?
- What is the availability of the data:
- Is the data in-house or with your suppliers?
- Is it centralised or fragmented?
- Is it structured or unstructured?
Spend time to complete a thorough reporting review before you reach for new tools and technology.
Determine your decision-making focus: Strategic vs Operational
As you carry out your review, take time to understand if you need to provide strategic or operational decision-making insights.
For example, do you need to report on business improvement or continuous improvement? Do you want to report on a specific project or improve aspects across an entire portfolio of projects?
Here are some typical reporting use cases as a starting point for consideration:
- Project costs and schedules
- Funder allocation
- Environment and safety
- Control and compliance
- Confidence building activity
- Automation of manual processes
Why are you creating a projects analysis capability?
Before you dive into your initiative, it’s vital to consider your goals. To help start the thought-process, here are some common areas of improvement for you to consider:
- Speed of decision-making: Are you looking to improve the pace and quality of your decision-making? How is decision-making impaired currently? What are the most important aspects you wish to improve?
- Aligning with business improvement: Do you want improved project reporting and analytics to help accelerate existing business improvement or change initiatives?
- Enhanced control/profit: Are you hoping to improve the control you have on complex projects? Is there a desire to drive better analytics for increased profitability?
- Building confidence/risk management: Do you want to increase stakeholder confidence and manage your risk more effectively?
- Showcasing data as a competitive advantage: Do you want to highlight the mature of your project reporting approach as a means of demonstrating leadership within the industry, perhaps for future clients?
Our recommendation would be not to tackle all of your goals at once. Instead, progress a couple of use cases or improvements you feel are relevant and achievable.
Starting small and delivering tangible quick wins is the best approach to maintaining progress and buy-in with project analytics.
Getting started (eating the elephant)
Now that you’ve completed a reporting review and shortlisted some initial uses cases for improvements, your next task is to get started.
After completing a number of these initiatives, here are some recommendations for a successful ‘startup‘ project based on our experience:
- Build an agile, iterative delivery process: Once you’ve received buy-in and funding, it may be tempting to ‘boil the ocean’ with an extensive program that tackles a broad range of use cases and improvements. Our experience highlights the need to start small with focused sprints that deliver tangible value in a realistic timeframe.
- Beware of technical debt: Be wary of adopting sophisticated visualisation technology too early. Tools like Power BI may appear like the ‘killer app’ for getting quick wins with project analytics, but they’ll hamper your progress and require substantial re-engineering if deployed too soon.
- Don’t underestimate the effort: Even with an agile approach, creating a project analytics capability is still a non-trivial exercise. Communicate to your sponsors and stakeholders the need for patience as you seek to discover, access, understand, and cleanse your project data sources.
Finally, despite the complexities of getting started with the technical aspects of project analytics, you can be assured that although the technology is non-trivial, it is solvable.
The number of successful programs benefitting from project analytics continues to rise each month and it’s encouraging to see the project analytics movement gathering pace.
In our next article in this project analytics series, we’ll take a look at the technical requirements in more detail so you can start to plan for your first project analytics initiative.
