In this article, we continue our discussion into the process of building out a complete Project Analytics capability for your major projects initiatives. 

Last week, we explored the engineering architecture required for a modern Project Analytics capability. This week, we look at how to create a roadmap from your Project Analytics pilot into a production-ready solution that is fit for the future.


Introducing the Phases of Project Analytics Deployment

Phase 1: Data Architecture Conception / Proof of Viability

We covered most of this phase in last week’s article that unpacked the topic of data engineering for Project Analytics.

Key milestones in phase 1 are to determine the availability of the data you require, and the viability of the architecture you have in mind for your Project Analytics initiative.

Coming out of this phase should be a roadmap of how your solution will be built and an ‘illustrator’ that supports any internal business case activity.

Phase 2: Building the Core Platform

During this phase, you will begin to leverage your earlier data engineering exploration to increase the level of data ‘ingestion’ into your Project Analytics platform. The goal here is to build a live demonstrator that possesses enough functionality to deliver value to the business.

For example, in phase 2 you’re looking to demonstrate:

Live connectivity to core systems: You’re looking to demonstrate that your analytics platform can pull in operational data, in an acceptable timeframe, and translate this live data into some form of insight

Data organisation/productionisation: As discussed earlier in this series, a lot of major projects reporting in the past has required substantial manual cleansing and manipulation of the data before it’s deemed ‘fit for purpose’ enough to hand over to senior management.

In phase 2, you’ll start letting go of those manual processes and start relying on the data engineering platform you created in Phase 1 to better organise and manipulate the data in a more automated fashion. You may still be some way off a fully operational, signed off solution, but your team should be putting in the right processes to ensure a more predictable result from the inbound operational data.

Blocker removal: At this phase of the journey, it’s not uncommon to start experiencing some blockers to your progress, these typically fall into the following categories:

  1. Organisational blockers
  2. Process blockers
  3. Data blockers
  4. IT blockers

Building out a Project Analytics capability requires a great deal of change; you’ll need to accept this and plan appropriately. For example, this may be the first time your organisation gets to agree on simple classifications and definitions of some key data terms. You’ll soon realise the importance of building a data governance strategy to set up data stewardship and accountabilities within major projects. The quality of your analytics will be greatly improved if each department comes to an agreement on the most critical data within the business.

Quite often, you’ll begin to shine a light on longstanding data quality issues that need addressing as you build out your analytics capability. This is to be expected, so don’t shy away from making organisational, process, data and IT recommendations that improve the final outcome of your analytics reporting requirements.

Phase 3: Production Build

In phase 2, you’ve been mostly building out a ‘beta’ version of the core platform, but in phase 3, you’re going to start extending your analytics platform to support production capabilities.

For example, you’ll be introducing different environments (e.g. Development/QA/Production) to coordinate regular cycles of production-ready software releases.

One challenge at this phase will be managing the wave of inflated expectations. What you’ve created by this point will be far more advanced than previous project reports so you’ll need to ensure you have a communications plan and clear roadmap for engaging the users and stakeholders.

You’ll also need to make it clear in those communications that, due to increased automation, there may be the occasional poor quality result coming through into the final analysis. This is to be expected as you scale up your production operation. The key is to eliminate the root-cause of any data defects, and follow up with some transparent discussions around what the users and stakeholders can expect from the data as it transitions through these early ‘growing pains’ of your production process.

Quite often, occasional reporting issues are not always highlighting technical issues, but required changes in culture. With the added emphasis on data automation, your project staff will need to get accustomed to improving their data entry and project data quality.

Other data challenges will become noticeable as your production environment ingests more data, particularly as you ‘widen the net’ for inbound data sources. A common issue will be the ‘single version of the truth’ problem that invariably arises when different applications, or even different departments, hold conflicting records. For example, it’s common for different systems to have differing project baseline data, for a variety of reasons.

At the end of phase 3, you would expect your production environment to be an ‘enterprise grade’ system, meeting whatever relevant IT, security, data protection and data governance policies and controls your organisation may impose.

Finally, phase 3 is where you will typically have enough resource and stability in your platform to start exploring any use cases for Artificial Intelligence and Machine Learning.

Phase 4: Transition Back to Business

At this phase, you’ll be looking to create a Business as Usual (BAU) scenario with your Project Analytics capability. Don’t underestimate the effort required to fully train and orientate the business on their obligations for taking over the solution.

Phase 4 is where you’ll be in a good position to integrate with other large data initiatives, if they exist. By this point you’ve already created a robust data platform so you can expose your data to these bigger programs as just another source of quality data, but be sure to apply data quality controls/tests for the data you supply. Likewise, you want to be checking for data quality on any inbound data you receive from other data initiatives.

During this phase, you can also start to realise the bigger benefits of Project Analytics by ‘democratising’ your data to project staff in need of good quality data and reporting insights. This project analysis ‘LEGO® set’ creates the building blocks of a self-service business intelligence capability, complete with a clean set of unified project data.

Finally, project staff can swap their spreadsheets and hours of manual data wrangling, for a trusted and fully operational project analytics environment.

The Story so far and Next Steps

In this series, we started off by examining the evolution of Project Analytics, how it is benefitting the Major Projects sector, and some foundational principles for getting started.

In the second article in this series, we examined the skills required to deliver effective Project Analytics and the steps required when building a case for smarter Project Analytics.

The third article explained how to demonstrate the viability of your data analytics platform and explored what’s required to showcase some early benefits.

In this fourth article, we’ve introduced the Four Phases of your analytics.

In the final article of this series, we’ll recap on all the steps you will have travelled so far, and outline how all of the typical Project Analytics use cases will come together, and who will benefit the most.

If you have any questions about any of the techniques we have discussed in this series, feel free to get in touch for more information.

About the Author

Richard CorderoyRichard Corderoy: I help enable the fantastic team at the Oakland Group to solve challenging business problems and realise new opportunities for our wide range of clients.

It’s always an exciting/hair raising journey to combine the potential of advanced analytics (including ‘Big Data’ and ‘Artificial Intelligence’) with the discipline of process and quality transformation all delivered in the context of a 35-year-old, non-nonsense Yorkshire based business! Follow Richard on Linkedin.

The Oakland Group delivers Project-Based Analytics. Helping businesses embark on the journey to get more from their data or helping them to solve particularly challenging analytical problems. Technology agnostic – we specialise in combining the best of new tech with the realities of corporate systems.

Process and Quality Improvement. Challenging perceptions around how process and quality improvement can help organisations and providing practical management and governance structures that bridge the gap between the ‘intent of management’ and the operational reality. Find out more.